Re: [PATCH] mm/memory.c: Mark wp_huge_pmd() inline to prevent build failure

2017-12-03 Thread Geert Uytterhoeven
On Sun, Dec 3, 2017 at 10:11 PM, Geert Uytterhoeven
 wrote:
> With gcc 4.1.2:
>
> mm/memory.o: In function `wp_huge_pmd':
> memory.c:(.text+0x9b4): undefined reference to `do_huge_pmd_wp_page'
>
> Interestingly, wp_huge_pmd() is emitted in the assembler output, but
> never called.
>
> Apparently replacing the call to pmd_write() in __handle_mm_fault() by a
> call to the more complex pmd_access_permitted() reduced the ability of
> the compiler to remove unused code.

An alternative would be to start using #ifdefs and dummies for the
!CONFIG_TRANSPARENT_HUGEPAGE case, instead of relying on the varying degree
of ability of the various compiler versions to do dead code analysis and
elimination.

> Fix this by marking wp_huge_pmd() inline, like was done in commit
> 91a90140f9987101 ("mm/memory.c: mark create_huge_pmd() inline to prevent
> build failure") for a similar problem.
>
> Fixes: c7da82b894e9eef6 ("mm: replace pmd_write with pmd_access_permitted in 
> fault + gup paths")
> Signed-off-by: Geert Uytterhoeven 
> ---
>  mm/memory.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 5eb3d2524bdc2823..f4d52847ca07a414 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3831,7 +3831,7 @@ static inline int create_huge_pmd(struct vm_fault *vmf)
> return VM_FAULT_FALLBACK;
>  }
>
> -static int wp_huge_pmd(struct vm_fault *vmf, pmd_t orig_pmd)
> +static inline int wp_huge_pmd(struct vm_fault *vmf, pmd_t orig_pmd)
>  {
> if (vma_is_anonymous(vmf->vma))
> return do_huge_pmd_wp_page(vmf, orig_pmd);

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH] mm/memory.c: Mark wp_huge_pmd() inline to prevent build failure

2017-12-03 Thread Geert Uytterhoeven
On Sun, Dec 3, 2017 at 10:11 PM, Geert Uytterhoeven
 wrote:
> With gcc 4.1.2:
>
> mm/memory.o: In function `wp_huge_pmd':
> memory.c:(.text+0x9b4): undefined reference to `do_huge_pmd_wp_page'
>
> Interestingly, wp_huge_pmd() is emitted in the assembler output, but
> never called.
>
> Apparently replacing the call to pmd_write() in __handle_mm_fault() by a
> call to the more complex pmd_access_permitted() reduced the ability of
> the compiler to remove unused code.

An alternative would be to start using #ifdefs and dummies for the
!CONFIG_TRANSPARENT_HUGEPAGE case, instead of relying on the varying degree
of ability of the various compiler versions to do dead code analysis and
elimination.

> Fix this by marking wp_huge_pmd() inline, like was done in commit
> 91a90140f9987101 ("mm/memory.c: mark create_huge_pmd() inline to prevent
> build failure") for a similar problem.
>
> Fixes: c7da82b894e9eef6 ("mm: replace pmd_write with pmd_access_permitted in 
> fault + gup paths")
> Signed-off-by: Geert Uytterhoeven 
> ---
>  mm/memory.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 5eb3d2524bdc2823..f4d52847ca07a414 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3831,7 +3831,7 @@ static inline int create_huge_pmd(struct vm_fault *vmf)
> return VM_FAULT_FALLBACK;
>  }
>
> -static int wp_huge_pmd(struct vm_fault *vmf, pmd_t orig_pmd)
> +static inline int wp_huge_pmd(struct vm_fault *vmf, pmd_t orig_pmd)
>  {
> if (vma_is_anonymous(vmf->vma))
> return do_huge_pmd_wp_page(vmf, orig_pmd);

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH 0/4] Move DP phy switch to PHY driver

2017-12-03 Thread Heiko Stübner
Hi Chris,

Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> Hi,
> >> 
> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> >>> Hi Doug
> >>> 
> >>> Thank you for mentioning this patch.
> >>> 
> >>> I think the focus of the discussion is: can we put the grf control bit
> >>> to
> >>> dts.
> >>> 
> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >>> "uphy_dp_sel"
> >>> 
> >>> can help to switch these 2 phy. So I think this bit can be considered as
> >>> a
> >>> part of
> >>> 
> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
> >>> (such as "pipe-status").
> >>> 
> >>> Put them to DTS file might be a accepted practice.
> >> 
> >> I guess the first step would be finding the person to make a decision.
> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> >> options:
> >> 
> >> 1. Land this series as-is.  This makes the new bit work just like all
> >> the other ones next to it.  If anyone happens to try to use an old
> >> device tree on a new kernel they'll break.  Seems rather unlikely
> >> given that the whole type C PHY is not really fully functional
> >> upstream, but technically this is a no-no from a device tree
> >> perspective.
> >> 
> >> 2. Change the series to make this property optional.  If it's not
> >> there then the code behaves like it always did.  This would address
> >> the "compatibility" problem but likely wouldn't actually help any real
> >> people, and it would be extra work.
> >> 
> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> put the table in the driver, keyed off the compatible string and base
> >> address if the IO memory.
> >> 
> >> 
> >> I can't make this decision.  It's up to those folks who would be
> >> landing the patch and I'd be happy with any of them.  What I'm less
> >> happy with, however, is the indecision preventing forward progress.
> >> We should pick one of the above things and land it.  My own personal
> >> bias is #1: just land the series.  No real people will be hurt and
> >> it's just adding another property that matches the ones next to it.
> > 
> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> > the past (some for the never used dp output), so personally I don't have
> > issues with going that route.
> > 
> >>  From a long term perspective (AKA how I'd write the next driver like
> >> 
> >> this) I personally lean towards to "tables in the driver, not in the
> >> device tree" but quite honestly I'm happy to take whatever direction
> >> the maintainers give.
> > 
> > It looks like we're in agreement here :-) . GRF stuff should not leak into
> > the devicetree, as it causes endless headaches later. But I guess we'll
> > need to live with the ones that happened so far.
> 
> So, the first step is: move all the private property of tcphy to
> drivers/phy/rockchip/phy-rockchip-typec.c.
> Second step: new a member: uphy-dp-sel.
> In my mind, we should have discussed these properties before, and then I
> moved them all into DTS.

Actually, I was agreeing with Doug, that we probably don't need to rework the 
type-c phy driver. As most properties for it are in the devicetree right now
we'll need to support them for backwards-compatiblity anyway.

And yes, there probably was discussion over dts vs. driver-table when the
type-c driver was introduced, but I either missed it or wasn't firm enough
back then ;-) .

Hence the "we'll need to live with it" for the type-c phy, but should not
do similar things in future drivers.


Heiko


Re: [PATCH 0/4] Move DP phy switch to PHY driver

2017-12-03 Thread Heiko Stübner
Hi Chris,

Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> Hi,
> >> 
> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> >>> Hi Doug
> >>> 
> >>> Thank you for mentioning this patch.
> >>> 
> >>> I think the focus of the discussion is: can we put the grf control bit
> >>> to
> >>> dts.
> >>> 
> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >>> "uphy_dp_sel"
> >>> 
> >>> can help to switch these 2 phy. So I think this bit can be considered as
> >>> a
> >>> part of
> >>> 
> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
> >>> (such as "pipe-status").
> >>> 
> >>> Put them to DTS file might be a accepted practice.
> >> 
> >> I guess the first step would be finding the person to make a decision.
> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> >> options:
> >> 
> >> 1. Land this series as-is.  This makes the new bit work just like all
> >> the other ones next to it.  If anyone happens to try to use an old
> >> device tree on a new kernel they'll break.  Seems rather unlikely
> >> given that the whole type C PHY is not really fully functional
> >> upstream, but technically this is a no-no from a device tree
> >> perspective.
> >> 
> >> 2. Change the series to make this property optional.  If it's not
> >> there then the code behaves like it always did.  This would address
> >> the "compatibility" problem but likely wouldn't actually help any real
> >> people, and it would be extra work.
> >> 
> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> put the table in the driver, keyed off the compatible string and base
> >> address if the IO memory.
> >> 
> >> 
> >> I can't make this decision.  It's up to those folks who would be
> >> landing the patch and I'd be happy with any of them.  What I'm less
> >> happy with, however, is the indecision preventing forward progress.
> >> We should pick one of the above things and land it.  My own personal
> >> bias is #1: just land the series.  No real people will be hurt and
> >> it's just adding another property that matches the ones next to it.
> > 
> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> > the past (some for the never used dp output), so personally I don't have
> > issues with going that route.
> > 
> >>  From a long term perspective (AKA how I'd write the next driver like
> >> 
> >> this) I personally lean towards to "tables in the driver, not in the
> >> device tree" but quite honestly I'm happy to take whatever direction
> >> the maintainers give.
> > 
> > It looks like we're in agreement here :-) . GRF stuff should not leak into
> > the devicetree, as it causes endless headaches later. But I guess we'll
> > need to live with the ones that happened so far.
> 
> So, the first step is: move all the private property of tcphy to
> drivers/phy/rockchip/phy-rockchip-typec.c.
> Second step: new a member: uphy-dp-sel.
> In my mind, we should have discussed these properties before, and then I
> moved them all into DTS.

Actually, I was agreeing with Doug, that we probably don't need to rework the 
type-c phy driver. As most properties for it are in the devicetree right now
we'll need to support them for backwards-compatiblity anyway.

And yes, there probably was discussion over dts vs. driver-table when the
type-c driver was introduced, but I either missed it or wasn't firm enough
back then ;-) .

Hence the "we'll need to live with it" for the type-c phy, but should not
do similar things in future drivers.


Heiko


Re: [PATCH] sched/rt: Do not pull from current CPU if only one cpu to pull

2017-12-03 Thread Juri Lelli
Hi Steve,

On 02/12/17 13:04, Steven Rostedt wrote:
> Daniel Wagner reported a crash on the beaglebone black. This is a
> single CPU architecture, and does not have a functional:
> arch_send_call_function_single_ipi() and can crash if that is called.
> 
> As it only has one CPU, it shouldn't be called, but if the kernel is
> compiled for SMP, the push/pull RT scheduling logic now calls it for
> irq_work if the one CPU is overloaded, it can use that function to call
> itself and crash the kernel.
> 
> Ideally, we should disable the SCHED_FEAT(RT_PUSH_IPI) if the system
> only has a single CPU. But SCHED_FEAT is a constant if sched debugging
> is turned off. Another fix can also be used, and this should also help
> with normal SMP machines. That is, do not initiate the pull code if
> there's only one RT overloaded CPU, and that CPU happens to be the
> current CPU that is scheduling in a lower priority task.
> 
> Even on a system with many CPUs, if there's many RT tasks waiting to
> run on a single CPU, and that CPU schedules in another RT task of lower
> priority, it will initiate the PULL logic in case there's a higher
> priority RT task on another CPU that is waiting to run. But if there is
> no other CPU with waiting RT tasks, it will initiate the RT pull logic
> on itself (as it still has RT tasks waiting to run). This is a wasted
> effort.
> 
> Not only does this help with SMP code where the current CPU is the only
> one with RT overloaded tasks, it should also solve the issue that
> Daniel encountered, because it will prevent the PULL logic from
> executing, as there's only one CPU on the system, and the check added
> here will cause it to exit the RT pull code.
> 
> Link: http://lkml.kernel.org/r/8c913cc2-b2e3-8c2e-e503-aff1428f8...@monom.org
> Fixes: 4bdced5c9 ("sched/rt: Simplify the IPI based RT balancing logic")
> Cc: sta...@vger.kernel.org
> Reported-by: Daniel Wagner 
> ---
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 4056c19ca3f0..665ace2fc558 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -2034,8 +2034,9 @@ static void pull_rt_task(struct rq *this_rq)
>   bool resched = false;
>   struct task_struct *p;
>   struct rq *src_rq;
> + int rt_overload_count = rt_overloaded(this_rq);
>  
> - if (likely(!rt_overloaded(this_rq)))
> + if (likely(!rt_overload_count))
>   return;
>  
>   /*
> @@ -2044,6 +2045,11 @@ static void pull_rt_task(struct rq *this_rq)
>*/
>   smp_rmb();
>  
> + /* If we are the only overloaded CPU do nothing */
> + if (rt_overload_count == 1 &&
> + cpumask_test_cpu(this_rq->cpu, this_rq->rd->rto_mask))
> + return;
> +

Right. I was wondering however if for the truly UP case we shouldn't be
initiating/queueing callbacks (pull/push) at all?

DEADLINE doesn't use (yet?) the PUSH_IPI, but we will need a similar
patch to keep logics aligned.

Best,

Juri


Re: [PATCH] sched/rt: Do not pull from current CPU if only one cpu to pull

2017-12-03 Thread Juri Lelli
Hi Steve,

On 02/12/17 13:04, Steven Rostedt wrote:
> Daniel Wagner reported a crash on the beaglebone black. This is a
> single CPU architecture, and does not have a functional:
> arch_send_call_function_single_ipi() and can crash if that is called.
> 
> As it only has one CPU, it shouldn't be called, but if the kernel is
> compiled for SMP, the push/pull RT scheduling logic now calls it for
> irq_work if the one CPU is overloaded, it can use that function to call
> itself and crash the kernel.
> 
> Ideally, we should disable the SCHED_FEAT(RT_PUSH_IPI) if the system
> only has a single CPU. But SCHED_FEAT is a constant if sched debugging
> is turned off. Another fix can also be used, and this should also help
> with normal SMP machines. That is, do not initiate the pull code if
> there's only one RT overloaded CPU, and that CPU happens to be the
> current CPU that is scheduling in a lower priority task.
> 
> Even on a system with many CPUs, if there's many RT tasks waiting to
> run on a single CPU, and that CPU schedules in another RT task of lower
> priority, it will initiate the PULL logic in case there's a higher
> priority RT task on another CPU that is waiting to run. But if there is
> no other CPU with waiting RT tasks, it will initiate the RT pull logic
> on itself (as it still has RT tasks waiting to run). This is a wasted
> effort.
> 
> Not only does this help with SMP code where the current CPU is the only
> one with RT overloaded tasks, it should also solve the issue that
> Daniel encountered, because it will prevent the PULL logic from
> executing, as there's only one CPU on the system, and the check added
> here will cause it to exit the RT pull code.
> 
> Link: http://lkml.kernel.org/r/8c913cc2-b2e3-8c2e-e503-aff1428f8...@monom.org
> Fixes: 4bdced5c9 ("sched/rt: Simplify the IPI based RT balancing logic")
> Cc: sta...@vger.kernel.org
> Reported-by: Daniel Wagner 
> ---
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 4056c19ca3f0..665ace2fc558 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -2034,8 +2034,9 @@ static void pull_rt_task(struct rq *this_rq)
>   bool resched = false;
>   struct task_struct *p;
>   struct rq *src_rq;
> + int rt_overload_count = rt_overloaded(this_rq);
>  
> - if (likely(!rt_overloaded(this_rq)))
> + if (likely(!rt_overload_count))
>   return;
>  
>   /*
> @@ -2044,6 +2045,11 @@ static void pull_rt_task(struct rq *this_rq)
>*/
>   smp_rmb();
>  
> + /* If we are the only overloaded CPU do nothing */
> + if (rt_overload_count == 1 &&
> + cpumask_test_cpu(this_rq->cpu, this_rq->rd->rto_mask))
> + return;
> +

Right. I was wondering however if for the truly UP case we shouldn't be
initiating/queueing callbacks (pull/push) at all?

DEADLINE doesn't use (yet?) the PUSH_IPI, but we will need a similar
patch to keep logics aligned.

Best,

Juri


Re: [PATCH v1 2/2] drm/tinydrm: add driver for ILI9225 panels

2017-12-03 Thread Daniel Vetter
On Fri, Dec 01, 2017 at 03:03:30PM +0100, Linus Walleij wrote:
> On Wed, Nov 8, 2017 at 4:52 AM, David Lechner  wrote:
> 
> > This adds a new driver for display panels based on the Ilitek ILI9225
> > controller.
> >
> > This was developed for a no-name panel with a red PCB that is commonly
> > marketed for Arduino. See .
> >
> > I really did try very hard to find a make and model for this panel, but
> > there doesn't seem to be one, so the best I can do is offer the picture
> > in the link above for identification.
> >
> > Signed-off-by: David Lechner 
> 
> Can you explain why tinydrm is not putting its panel drivers in
> drivers/gpu/drm/panel?
> 
> I guess everybody knows except me, it's usually like that :(
> 
> I am anyways working on a driver for Ilitek 9322 that I want
> to land in drivers/gpu/drm/panel. Here is the last iteration:
> https://lists.freedesktop.org/archives/dri-devel/2017-August/150205.html
> Yeah I got sidetracked. OK I will get to it now.
> 
> There are some similarities with the code I'm seeing here
> but I believe they are essentially different. But it will be hard
> to share code if you put the driver in the tinydrm framework.
> 
> I guess you have also seen:
> drivers/video/backlight/ili922x.c
> ?
> 
> Stefano Babic who wrote the backlight driver is available for
> reviewing, so includ him in follow-ups (added to To: line).
> 
> I'm putting you on CC as I'm rewriting it a bit after the DT
> maintainers review, will try to repost ASAP.

Bit more historical context: We tried using drm_panel in tinydrm, but that
didn't really fit to well (as Noralf explains, tinydrm is kinda more for
stand-alone panels). But tinydrm is also a bit too much midlayer-y still,
so there's a bunch of todo items capture in Documentation/gpu/todo.rst. In
the end we shouldn't need a special tinydrm driver, that should be covered
by the usual drm helpers.

Might be worth it to at least capture/summarize some of the reasons for
why tinydrm doesn't use drm_panel, and what it would take to better share
code (or maybe that's just a silly idea, not the first duplicated driver
in drm).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH v1 2/2] drm/tinydrm: add driver for ILI9225 panels

2017-12-03 Thread Daniel Vetter
On Fri, Dec 01, 2017 at 03:03:30PM +0100, Linus Walleij wrote:
> On Wed, Nov 8, 2017 at 4:52 AM, David Lechner  wrote:
> 
> > This adds a new driver for display panels based on the Ilitek ILI9225
> > controller.
> >
> > This was developed for a no-name panel with a red PCB that is commonly
> > marketed for Arduino. See .
> >
> > I really did try very hard to find a make and model for this panel, but
> > there doesn't seem to be one, so the best I can do is offer the picture
> > in the link above for identification.
> >
> > Signed-off-by: David Lechner 
> 
> Can you explain why tinydrm is not putting its panel drivers in
> drivers/gpu/drm/panel?
> 
> I guess everybody knows except me, it's usually like that :(
> 
> I am anyways working on a driver for Ilitek 9322 that I want
> to land in drivers/gpu/drm/panel. Here is the last iteration:
> https://lists.freedesktop.org/archives/dri-devel/2017-August/150205.html
> Yeah I got sidetracked. OK I will get to it now.
> 
> There are some similarities with the code I'm seeing here
> but I believe they are essentially different. But it will be hard
> to share code if you put the driver in the tinydrm framework.
> 
> I guess you have also seen:
> drivers/video/backlight/ili922x.c
> ?
> 
> Stefano Babic who wrote the backlight driver is available for
> reviewing, so includ him in follow-ups (added to To: line).
> 
> I'm putting you on CC as I'm rewriting it a bit after the DT
> maintainers review, will try to repost ASAP.

Bit more historical context: We tried using drm_panel in tinydrm, but that
didn't really fit to well (as Noralf explains, tinydrm is kinda more for
stand-alone panels). But tinydrm is also a bit too much midlayer-y still,
so there's a bunch of todo items capture in Documentation/gpu/todo.rst. In
the end we shouldn't need a special tinydrm driver, that should be covered
by the usual drm helpers.

Might be worth it to at least capture/summarize some of the reasons for
why tinydrm doesn't use drm_panel, and what it would take to better share
code (or maybe that's just a silly idea, not the first duplicated driver
in drm).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH] treewide: remove duplicate includes

2017-12-03 Thread Greg KH
On Mon, Dec 04, 2017 at 03:19:39AM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Unit Testing:
> 
> - build successful
> - LTP testsuite passes.
> - checkpatch.pl passes
> 
> Signed-off-by: Pravin Shedge 

Please break this up per-subsystem, like any other cleanup patch, and
send it out that way.  As it is, no one can take such a patch.

thanks,

greg k-h


Re: [PATCH] treewide: remove duplicate includes

2017-12-03 Thread Greg KH
On Mon, Dec 04, 2017 at 03:19:39AM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Unit Testing:
> 
> - build successful
> - LTP testsuite passes.
> - checkpatch.pl passes
> 
> Signed-off-by: Pravin Shedge 

Please break this up per-subsystem, like any other cleanup patch, and
send it out that way.  As it is, no one can take such a patch.

thanks,

greg k-h


Re: [GIT PULL] hash addresses printed with %p

2017-12-03 Thread Greg Kroah-Hartman
On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Young wrote:
> +#define __ATTR_IRUSR(_name) {
> \
> + .attr   = { .name = __stringify(_name), .mode = S_IRUSR },  \
> + .show   = _name##_show, \
> +}

Ick, no, as others, including Linus, have said, using IRUSER is a pain
in the ass to try to look up and remember what it is...

Just use __ATTR() please, it should be fine for what you need to do,
which is special-case a sysfs attribute.

thanks,

greg k-h


Re: [GIT PULL] hash addresses printed with %p

2017-12-03 Thread Greg Kroah-Hartman
On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Young wrote:
> +#define __ATTR_IRUSR(_name) {
> \
> + .attr   = { .name = __stringify(_name), .mode = S_IRUSR },  \
> + .show   = _name##_show, \
> +}

Ick, no, as others, including Linus, have said, using IRUSER is a pain
in the ass to try to look up and remember what it is...

Just use __ATTR() please, it should be fine for what you need to do,
which is special-case a sysfs attribute.

thanks,

greg k-h


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-03 Thread Jiri Olsa
On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> Hi Jiri,
> 
> On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > From: Jiri Olsa 
> > 
> > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > hardened specs from redhat-rpm-config package. We apply them only
> > for perl/python objects, which makes them not compatible with the
> > rest of the objects and the build fails with:
> > 
> >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > `.text' can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> >   collect2: error: ld returned 1 exit status
> >   make[2]: *** [Makefile.perf:507: perf] Error 1
> >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> >   make: *** [Makefile:69: all] Error 2
> > 
> > Mainly it's caused by perl/python objects being compiled with:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > 
> > which prevent the final link impossible, because it will check
> > for 'proper' objects with following option:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> 
> Just for curiousity, could you please show me the contents of the two
> files?  (Are they big?)

# cat /usr/lib/rpm/redhat/redhat-hardened-ld
*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}}

*link:
+ -z now


# cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}


jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-03 Thread Jiri Olsa
On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> Hi Jiri,
> 
> On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > From: Jiri Olsa 
> > 
> > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > hardened specs from redhat-rpm-config package. We apply them only
> > for perl/python objects, which makes them not compatible with the
> > rest of the objects and the build fails with:
> > 
> >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > `.text' can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> >   collect2: error: ld returned 1 exit status
> >   make[2]: *** [Makefile.perf:507: perf] Error 1
> >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> >   make: *** [Makefile:69: all] Error 2
> > 
> > Mainly it's caused by perl/python objects being compiled with:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > 
> > which prevent the final link impossible, because it will check
> > for 'proper' objects with following option:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> 
> Just for curiousity, could you please show me the contents of the two
> files?  (Are they big?)

# cat /usr/lib/rpm/redhat/redhat-hardened-ld
*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}}

*link:
+ -z now


# cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}


jirka


Re: [PATCH] Make FSI a menuconfig to ease disabling it all

2017-12-03 Thread Greg KH
On Mon, Dec 04, 2017 at 02:56:32PM +0800, Jeremy Kerr wrote:
> Hi Vincent,
> 
> > No need to get into the submenu to disable all FSI-related config entries
> 
> Sounds reasonable to me.
> 
> Acked-by: Jeremy Kerr 
> 
> Greg: do you want Joel (or me) to manage FSI patches, or would you
> prefer to take this directly?

I can take this with your ack if you want me to.  Give me a few days to
catch up on things.

thanks,

greg k-h


Re: [PATCH] Make FSI a menuconfig to ease disabling it all

2017-12-03 Thread Greg KH
On Mon, Dec 04, 2017 at 02:56:32PM +0800, Jeremy Kerr wrote:
> Hi Vincent,
> 
> > No need to get into the submenu to disable all FSI-related config entries
> 
> Sounds reasonable to me.
> 
> Acked-by: Jeremy Kerr 
> 
> Greg: do you want Joel (or me) to manage FSI patches, or would you
> prefer to take this directly?

I can take this with your ack if you want me to.  Give me a few days to
catch up on things.

thanks,

greg k-h


Re: [PATCH 1/3] vhost: fix skb leak in handle_rx()

2017-12-03 Thread Jason Wang



On 2017年12月01日 22:37, Michael S. Tsirkin wrote:

On Fri, Dec 01, 2017 at 03:11:05PM +0800, Jason Wang wrote:


On 2017年12月01日 13:54, w...@redhat.com wrote:

From: Wei Xu 

Matthew found a roughly 40% tcp throughput regression with commit
c67df11f(vhost_net: try batch dequing from skb array) as discussed
in the following thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html

Eventually we figured out that it was a skb leak in handle_rx()
when sending packets to the VM. This usually happens when a guest
can not drain out vq as fast as vhost fills in, afterwards it sets
off the traffic jam and leaks skb(s) which occurs as no headcount
to send on the vq from vhost side.

This can be avoided by making sure we have got enough headcount
before actually consuming a skb from the batched rx array while
transmitting, which is simply done by moving checking the zero
headcount a bit ahead.

Signed-off-by: Wei Xu 
Reported-by: Matthew Rosato 
---
   drivers/vhost/net.c | 20 ++--
   1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8d626d7..c7bdeb6 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -778,16 +778,6 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
-   if (nvq->rx_array)
-   msg.msg_control = vhost_net_buf_consume(>rxq);
-   /* On overrun, truncate and discard */
-   if (unlikely(headcount > UIO_MAXIOV)) {
-   iov_iter_init(_iter, READ, vq->iov, 1, 1);
-   err = sock->ops->recvmsg(sock, ,
-1, MSG_DONTWAIT | MSG_TRUNC);
-   pr_debug("Discarded rx packet: len %zd\n", sock_len);
-   continue;
-   }
/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
@@ -800,6 +790,16 @@ static void handle_rx(struct vhost_net *net)
 * they refilled. */
goto out;
}
+   if (nvq->rx_array)
+   msg.msg_control = vhost_net_buf_consume(>rxq);
+   /* On overrun, truncate and discard */
+   if (unlikely(headcount > UIO_MAXIOV)) {
+   iov_iter_init(_iter, READ, vq->iov, 1, 1);
+   err = sock->ops->recvmsg(sock, ,
+1, MSG_DONTWAIT | MSG_TRUNC);
+   pr_debug("Discarded rx packet: len %zd\n", sock_len);
+   continue;
+   }
/* We don't need to be notified again. */
iov_iter_init(_iter, READ, vq->iov, in, vhost_len);
fixup = msg.msg_iter;

I suggest to reorder this patch to 3/3.

Thanks

Why? This doesn't cause any new leaks, does it?



It doesn't, just think it can ease the downstream back porting in case 
patch 2-3 were missed if somebody did a bisect and just backport patch 1.


Thanks


Re: [PATCH 1/3] vhost: fix skb leak in handle_rx()

2017-12-03 Thread Jason Wang



On 2017年12月01日 22:37, Michael S. Tsirkin wrote:

On Fri, Dec 01, 2017 at 03:11:05PM +0800, Jason Wang wrote:


On 2017年12月01日 13:54, w...@redhat.com wrote:

From: Wei Xu 

Matthew found a roughly 40% tcp throughput regression with commit
c67df11f(vhost_net: try batch dequing from skb array) as discussed
in the following thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html

Eventually we figured out that it was a skb leak in handle_rx()
when sending packets to the VM. This usually happens when a guest
can not drain out vq as fast as vhost fills in, afterwards it sets
off the traffic jam and leaks skb(s) which occurs as no headcount
to send on the vq from vhost side.

This can be avoided by making sure we have got enough headcount
before actually consuming a skb from the batched rx array while
transmitting, which is simply done by moving checking the zero
headcount a bit ahead.

Signed-off-by: Wei Xu 
Reported-by: Matthew Rosato 
---
   drivers/vhost/net.c | 20 ++--
   1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8d626d7..c7bdeb6 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -778,16 +778,6 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
-   if (nvq->rx_array)
-   msg.msg_control = vhost_net_buf_consume(>rxq);
-   /* On overrun, truncate and discard */
-   if (unlikely(headcount > UIO_MAXIOV)) {
-   iov_iter_init(_iter, READ, vq->iov, 1, 1);
-   err = sock->ops->recvmsg(sock, ,
-1, MSG_DONTWAIT | MSG_TRUNC);
-   pr_debug("Discarded rx packet: len %zd\n", sock_len);
-   continue;
-   }
/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
@@ -800,6 +790,16 @@ static void handle_rx(struct vhost_net *net)
 * they refilled. */
goto out;
}
+   if (nvq->rx_array)
+   msg.msg_control = vhost_net_buf_consume(>rxq);
+   /* On overrun, truncate and discard */
+   if (unlikely(headcount > UIO_MAXIOV)) {
+   iov_iter_init(_iter, READ, vq->iov, 1, 1);
+   err = sock->ops->recvmsg(sock, ,
+1, MSG_DONTWAIT | MSG_TRUNC);
+   pr_debug("Discarded rx packet: len %zd\n", sock_len);
+   continue;
+   }
/* We don't need to be notified again. */
iov_iter_init(_iter, READ, vq->iov, in, vhost_len);
fixup = msg.msg_iter;

I suggest to reorder this patch to 3/3.

Thanks

Why? This doesn't cause any new leaks, does it?



It doesn't, just think it can ease the downstream back porting in case 
patch 2-3 were missed if somebody did a bisect and just backport patch 1.


Thanks


[RESEND PATCH v3 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

2017-12-03 Thread Lin Huang
The Innolux P097PFG panel is 9.7" panel with 1536X2048
resolution, it reuse P079ZCA panel driver, so improve
p079ZCA dt-binding to support P097PFG.

Signed-off-by: Lin Huang 
---
 .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
index d0f5516..8cadd8c 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -1,13 +1,18 @@
 Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
 
 Required properties:
-- compatible: should be "innolux,p079zca"
+- compatible: should be should be one of the following.
+-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel
+-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel
 - reg: DSI virtual channel of the peripheral
-- power-supply: phandle of the regulator that provides the supply voltage
 - enable-gpios: panel enable gpio
 
 Optional properties:
 - backlight: phandle of the backlight device attached to the panel
+- power-supply: phandle of the regulator that provides the supply voltage
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
 
 Example:
 
@@ -16,6 +21,8 @@ Example:
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
+   avdd-supply = <...>;
+   avee-supply = <...>;
backlight = <>;
enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
};
-- 
2.7.4



[RESEND PATCH v3 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

2017-12-03 Thread Lin Huang
The Innolux P097PFG panel is 9.7" panel with 1536X2048
resolution, it reuse P079ZCA panel driver, so improve
p079ZCA dt-binding to support P097PFG.

Signed-off-by: Lin Huang 
---
 .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
index d0f5516..8cadd8c 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -1,13 +1,18 @@
 Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
 
 Required properties:
-- compatible: should be "innolux,p079zca"
+- compatible: should be should be one of the following.
+-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel
+-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel
 - reg: DSI virtual channel of the peripheral
-- power-supply: phandle of the regulator that provides the supply voltage
 - enable-gpios: panel enable gpio
 
 Optional properties:
 - backlight: phandle of the backlight device attached to the panel
+- power-supply: phandle of the regulator that provides the supply voltage
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
 
 Example:
 
@@ -16,6 +21,8 @@ Example:
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
+   avdd-supply = <...>;
+   avee-supply = <...>;
backlight = <>;
enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
};
-- 
2.7.4



[RESEND PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

2017-12-03 Thread Lin Huang
Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet 
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support 
P097PFG panel in another patch 

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 147 ++
 1 file changed, 105 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..1597744 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,32 @@
 
 #include 
 
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int bpc;
+   struct {
+   unsigned int width;
+   unsigned int height;
+   } size;
+};
+
+struct panel_desc_dsi {
+   struct panel_desc desc;
+
+   unsigned long flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+};
+
 struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+   const struct panel_desc_dsi *dsi_desc;
 
struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;
struct gpio_desc *enable_gpio;
 
bool prepared;
@@ -78,9 +98,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
 
-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;
+   regulator_disable(innolux->avee);
+   regulator_disable(innolux->avdd);
+   regulator_disable(innolux->vddi);
 
innolux->prepared = false;
 
@@ -97,10 +117,18 @@ static int innolux_panel_prepare(struct drm_panel *panel)
 
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
 
-   err = regulator_enable(innolux->supply);
+   err = regulator_enable(innolux->vddi);
if (err < 0)
return err;
 
+   err = regulator_enable(innolux->avdd);
+   if (err < 0)
+   goto disable_vddi;
+
+   err = regulator_enable(innolux->avee);
+   if (err < 0)
+   goto disable_avdd;
+
/* T2: 15ms - 1000ms */
usleep_range(15000, 16000);
 
@@ -134,12 +162,13 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
 
 poweroff:
-   regulator_err = regulator_disable(innolux->supply);
-   if (regulator_err)
-   DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+   regulator_disable(innolux->avee);
+disable_avdd:
+   regulator_disable(innolux->avdd);
+disable_vddi:
+   regulator_disable(innolux->vddi);
+
return err;
 }
 
@@ -164,7 +193,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
 }
 
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -177,15 +206,31 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
 };
 
+static const struct panel_desc_dsi innolux_p079zca_panel_desc = {
+   .desc = {
+   .modes = _p079zca_mode,
+   .bpc = 8,
+   .size = {
+   .width = 120,
+   .height = 160,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   const struct drm_display_mode *m = innolux->dsi_desc->desc.modes;
 
-   mode = drm_mode_duplicate(panel->drm, _mode);
+   mode = drm_mode_duplicate(panel->drm, m);
if (!mode) {
DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ m->hdisplay, m->vdisplay, m->vrefresh);
return -ENOMEM;
}
 
@@ -193,9 +238,11 @@ static int innolux_panel_get_modes(struct drm_panel *panel)
 
drm_mode_probed_add(panel->connector, mode);
 
-   panel->connector->display_info.width_mm = 120;
-   panel->connector->display_info.height_mm = 160;
-   panel->connector->display_info.bpc = 8;
+   panel->connector->display_info.width_mm =
+   innolux->dsi_desc->desc.size.width;
+   

[RESEND PATCH v3 2/3] drm/panel: support Innolux P097PFG panel

2017-12-03 Thread Lin Huang
Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
the Innolux P079ZCA panel driver.

Signed-off-by: Lin Huang 
---
 drivers/gpu/drm/panel/Kconfig |  9 
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 31 +++
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 726f3fb..429cf59 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -29,15 +29,14 @@ config DRM_PANEL_SIMPLE
  low power state.
 
 config DRM_PANEL_INNOLUX_P079ZCA
-   tristate "Innolux P079ZCA panel"
+   tristate "Innolux P079ZCA or P097PFG panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to enable support for Innolux P079ZCA
- TFT-LCD modules. The panel has a 1024x768 resolution and uses
- 24 bit RGB per pixel. It provides a MIPI DSI interface to
- the host and has a built-in LED backlight.
+ Say Y here if you want to enable support for Innolux P079ZCA or
+ Innolux P097PFG panel. They provide a MIPI DSI interface to
+ the host and have a built-in LED backlight.
 
 config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 1597744..5d690b7 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -221,6 +221,34 @@ static const struct panel_desc_dsi 
innolux_p079zca_panel_desc = {
.lanes = 4,
 };
 
+static const struct drm_display_mode innolux_p097pfg_mode = {
+   .clock = 22,
+   .hdisplay = 1536,
+   .hsync_start = 1536 + 100,
+   .hsync_end = 1536 + 100 + 24,
+   .htotal = 1536 + 100 + 24 + 100,
+   .vdisplay = 2048,
+   .vsync_start = 2048 + 18,
+   .vsync_end = 2048 + 18 + 2,
+   .vtotal = 2048 + 18 + 2 + 18,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc_dsi innolux_p097pfg_panel_desc = {
+   .desc = {
+   .modes = _p097pfg_mode,
+   .bpc = 8,
+   .size = {
+   .width = 147,
+   .height = 196,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 8,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
@@ -259,6 +287,9 @@ static const struct of_device_id innolux_of_match[] = {
{ .compatible = "innolux,p079zca",
  .data = _p079zca_panel_desc
},
+   { .compatible = "innolux,p097pfg",
+ .data = _p097pfg_panel_desc
+   }
 };
 MODULE_DEVICE_TABLE(of, innolux_of_match);
 
-- 
2.7.4



[RESEND PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

2017-12-03 Thread Lin Huang
Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet 
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support 
P097PFG panel in another patch 

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 147 ++
 1 file changed, 105 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..1597744 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,32 @@
 
 #include 
 
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int bpc;
+   struct {
+   unsigned int width;
+   unsigned int height;
+   } size;
+};
+
+struct panel_desc_dsi {
+   struct panel_desc desc;
+
+   unsigned long flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+};
+
 struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+   const struct panel_desc_dsi *dsi_desc;
 
struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;
struct gpio_desc *enable_gpio;
 
bool prepared;
@@ -78,9 +98,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
 
-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;
+   regulator_disable(innolux->avee);
+   regulator_disable(innolux->avdd);
+   regulator_disable(innolux->vddi);
 
innolux->prepared = false;
 
@@ -97,10 +117,18 @@ static int innolux_panel_prepare(struct drm_panel *panel)
 
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
 
-   err = regulator_enable(innolux->supply);
+   err = regulator_enable(innolux->vddi);
if (err < 0)
return err;
 
+   err = regulator_enable(innolux->avdd);
+   if (err < 0)
+   goto disable_vddi;
+
+   err = regulator_enable(innolux->avee);
+   if (err < 0)
+   goto disable_avdd;
+
/* T2: 15ms - 1000ms */
usleep_range(15000, 16000);
 
@@ -134,12 +162,13 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
 
 poweroff:
-   regulator_err = regulator_disable(innolux->supply);
-   if (regulator_err)
-   DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+   regulator_disable(innolux->avee);
+disable_avdd:
+   regulator_disable(innolux->avdd);
+disable_vddi:
+   regulator_disable(innolux->vddi);
+
return err;
 }
 
@@ -164,7 +193,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
 }
 
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -177,15 +206,31 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
 };
 
+static const struct panel_desc_dsi innolux_p079zca_panel_desc = {
+   .desc = {
+   .modes = _p079zca_mode,
+   .bpc = 8,
+   .size = {
+   .width = 120,
+   .height = 160,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   const struct drm_display_mode *m = innolux->dsi_desc->desc.modes;
 
-   mode = drm_mode_duplicate(panel->drm, _mode);
+   mode = drm_mode_duplicate(panel->drm, m);
if (!mode) {
DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ m->hdisplay, m->vdisplay, m->vrefresh);
return -ENOMEM;
}
 
@@ -193,9 +238,11 @@ static int innolux_panel_get_modes(struct drm_panel *panel)
 
drm_mode_probed_add(panel->connector, mode);
 
-   panel->connector->display_info.width_mm = 120;
-   panel->connector->display_info.height_mm = 160;
-   panel->connector->display_info.bpc = 8;
+   panel->connector->display_info.width_mm =
+   innolux->dsi_desc->desc.size.width;
+   

[RESEND PATCH v3 2/3] drm/panel: support Innolux P097PFG panel

2017-12-03 Thread Lin Huang
Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
the Innolux P079ZCA panel driver.

Signed-off-by: Lin Huang 
---
 drivers/gpu/drm/panel/Kconfig |  9 
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 31 +++
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 726f3fb..429cf59 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -29,15 +29,14 @@ config DRM_PANEL_SIMPLE
  low power state.
 
 config DRM_PANEL_INNOLUX_P079ZCA
-   tristate "Innolux P079ZCA panel"
+   tristate "Innolux P079ZCA or P097PFG panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to enable support for Innolux P079ZCA
- TFT-LCD modules. The panel has a 1024x768 resolution and uses
- 24 bit RGB per pixel. It provides a MIPI DSI interface to
- the host and has a built-in LED backlight.
+ Say Y here if you want to enable support for Innolux P079ZCA or
+ Innolux P097PFG panel. They provide a MIPI DSI interface to
+ the host and have a built-in LED backlight.
 
 config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 1597744..5d690b7 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -221,6 +221,34 @@ static const struct panel_desc_dsi 
innolux_p079zca_panel_desc = {
.lanes = 4,
 };
 
+static const struct drm_display_mode innolux_p097pfg_mode = {
+   .clock = 22,
+   .hdisplay = 1536,
+   .hsync_start = 1536 + 100,
+   .hsync_end = 1536 + 100 + 24,
+   .htotal = 1536 + 100 + 24 + 100,
+   .vdisplay = 2048,
+   .vsync_start = 2048 + 18,
+   .vsync_end = 2048 + 18 + 2,
+   .vtotal = 2048 + 18 + 2 + 18,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc_dsi innolux_p097pfg_panel_desc = {
+   .desc = {
+   .modes = _p097pfg_mode,
+   .bpc = 8,
+   .size = {
+   .width = 147,
+   .height = 196,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 8,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
@@ -259,6 +287,9 @@ static const struct of_device_id innolux_of_match[] = {
{ .compatible = "innolux,p079zca",
  .data = _p079zca_panel_desc
},
+   { .compatible = "innolux,p097pfg",
+ .data = _p097pfg_panel_desc
+   }
 };
 MODULE_DEVICE_TABLE(of, innolux_of_match);
 
-- 
2.7.4



[PATCH v3 2/3] drm/panel: support Innolux P097PFG panel

2017-12-03 Thread Lin Huang
Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
the Innolux P079ZCA panel driver.

Signed-off-by: Lin Huang 
---
 drivers/gpu/drm/panel/Kconfig |  9 
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 31 +++
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 726f3fb..429cf59 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -29,15 +29,14 @@ config DRM_PANEL_SIMPLE
  low power state.
 
 config DRM_PANEL_INNOLUX_P079ZCA
-   tristate "Innolux P079ZCA panel"
+   tristate "Innolux P079ZCA or P097PFG panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to enable support for Innolux P079ZCA
- TFT-LCD modules. The panel has a 1024x768 resolution and uses
- 24 bit RGB per pixel. It provides a MIPI DSI interface to
- the host and has a built-in LED backlight.
+ Say Y here if you want to enable support for Innolux P079ZCA or
+ Innolux P097PFG panel. They provide a MIPI DSI interface to
+ the host and have a built-in LED backlight.
 
 config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 1597744..5d690b7 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -221,6 +221,34 @@ static const struct panel_desc_dsi 
innolux_p079zca_panel_desc = {
.lanes = 4,
 };
 
+static const struct drm_display_mode innolux_p097pfg_mode = {
+   .clock = 22,
+   .hdisplay = 1536,
+   .hsync_start = 1536 + 100,
+   .hsync_end = 1536 + 100 + 24,
+   .htotal = 1536 + 100 + 24 + 100,
+   .vdisplay = 2048,
+   .vsync_start = 2048 + 18,
+   .vsync_end = 2048 + 18 + 2,
+   .vtotal = 2048 + 18 + 2 + 18,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc_dsi innolux_p097pfg_panel_desc = {
+   .desc = {
+   .modes = _p097pfg_mode,
+   .bpc = 8,
+   .size = {
+   .width = 147,
+   .height = 196,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 8,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
@@ -259,6 +287,9 @@ static const struct of_device_id innolux_of_match[] = {
{ .compatible = "innolux,p079zca",
  .data = _p079zca_panel_desc
},
+   { .compatible = "innolux,p097pfg",
+ .data = _p097pfg_panel_desc
+   }
 };
 MODULE_DEVICE_TABLE(of, innolux_of_match);
 
-- 
2.7.4



[PATCH v3 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

2017-12-03 Thread Lin Huang
The Innolux P097PFG panel is 9.7" panel with 1536X2048
resolution, it reuse P079ZCA panel driver, so improve
p079ZCA dt-binding to support P097PFG.

Change-Id: I8704914898fe53b734d31fbe646df8aa5fd8b30d
Signed-off-by: Lin Huang 
---
 .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
index d0f5516..8cadd8c 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -1,13 +1,18 @@
 Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
 
 Required properties:
-- compatible: should be "innolux,p079zca"
+- compatible: should be should be one of the following.
+-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel
+-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel
 - reg: DSI virtual channel of the peripheral
-- power-supply: phandle of the regulator that provides the supply voltage
 - enable-gpios: panel enable gpio
 
 Optional properties:
 - backlight: phandle of the backlight device attached to the panel
+- power-supply: phandle of the regulator that provides the supply voltage
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
 
 Example:
 
@@ -16,6 +21,8 @@ Example:
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
+   avdd-supply = <...>;
+   avee-supply = <...>;
backlight = <>;
enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
};
-- 
2.7.4



[PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

2017-12-03 Thread Lin Huang
Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet 
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support 
P097PFG panel in another patch 

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 147 ++
 1 file changed, 105 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..1597744 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,32 @@
 
 #include 
 
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int bpc;
+   struct {
+   unsigned int width;
+   unsigned int height;
+   } size;
+};
+
+struct panel_desc_dsi {
+   struct panel_desc desc;
+
+   unsigned long flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+};
+
 struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+   const struct panel_desc_dsi *dsi_desc;
 
struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;
struct gpio_desc *enable_gpio;
 
bool prepared;
@@ -78,9 +98,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
 
-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;
+   regulator_disable(innolux->avee);
+   regulator_disable(innolux->avdd);
+   regulator_disable(innolux->vddi);
 
innolux->prepared = false;
 
@@ -97,10 +117,18 @@ static int innolux_panel_prepare(struct drm_panel *panel)
 
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
 
-   err = regulator_enable(innolux->supply);
+   err = regulator_enable(innolux->vddi);
if (err < 0)
return err;
 
+   err = regulator_enable(innolux->avdd);
+   if (err < 0)
+   goto disable_vddi;
+
+   err = regulator_enable(innolux->avee);
+   if (err < 0)
+   goto disable_avdd;
+
/* T2: 15ms - 1000ms */
usleep_range(15000, 16000);
 
@@ -134,12 +162,13 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
 
 poweroff:
-   regulator_err = regulator_disable(innolux->supply);
-   if (regulator_err)
-   DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+   regulator_disable(innolux->avee);
+disable_avdd:
+   regulator_disable(innolux->avdd);
+disable_vddi:
+   regulator_disable(innolux->vddi);
+
return err;
 }
 
@@ -164,7 +193,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
 }
 
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -177,15 +206,31 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
 };
 
+static const struct panel_desc_dsi innolux_p079zca_panel_desc = {
+   .desc = {
+   .modes = _p079zca_mode,
+   .bpc = 8,
+   .size = {
+   .width = 120,
+   .height = 160,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   const struct drm_display_mode *m = innolux->dsi_desc->desc.modes;
 
-   mode = drm_mode_duplicate(panel->drm, _mode);
+   mode = drm_mode_duplicate(panel->drm, m);
if (!mode) {
DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ m->hdisplay, m->vdisplay, m->vrefresh);
return -ENOMEM;
}
 
@@ -193,9 +238,11 @@ static int innolux_panel_get_modes(struct drm_panel *panel)
 
drm_mode_probed_add(panel->connector, mode);
 
-   panel->connector->display_info.width_mm = 120;
-   panel->connector->display_info.height_mm = 160;
-   panel->connector->display_info.bpc = 8;
+   panel->connector->display_info.width_mm =
+   innolux->dsi_desc->desc.size.width;
+   

[PATCH v3 2/3] drm/panel: support Innolux P097PFG panel

2017-12-03 Thread Lin Huang
Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
the Innolux P079ZCA panel driver.

Signed-off-by: Lin Huang 
---
 drivers/gpu/drm/panel/Kconfig |  9 
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 31 +++
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 726f3fb..429cf59 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -29,15 +29,14 @@ config DRM_PANEL_SIMPLE
  low power state.
 
 config DRM_PANEL_INNOLUX_P079ZCA
-   tristate "Innolux P079ZCA panel"
+   tristate "Innolux P079ZCA or P097PFG panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to enable support for Innolux P079ZCA
- TFT-LCD modules. The panel has a 1024x768 resolution and uses
- 24 bit RGB per pixel. It provides a MIPI DSI interface to
- the host and has a built-in LED backlight.
+ Say Y here if you want to enable support for Innolux P079ZCA or
+ Innolux P097PFG panel. They provide a MIPI DSI interface to
+ the host and have a built-in LED backlight.
 
 config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 1597744..5d690b7 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -221,6 +221,34 @@ static const struct panel_desc_dsi 
innolux_p079zca_panel_desc = {
.lanes = 4,
 };
 
+static const struct drm_display_mode innolux_p097pfg_mode = {
+   .clock = 22,
+   .hdisplay = 1536,
+   .hsync_start = 1536 + 100,
+   .hsync_end = 1536 + 100 + 24,
+   .htotal = 1536 + 100 + 24 + 100,
+   .vdisplay = 2048,
+   .vsync_start = 2048 + 18,
+   .vsync_end = 2048 + 18 + 2,
+   .vtotal = 2048 + 18 + 2 + 18,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc_dsi innolux_p097pfg_panel_desc = {
+   .desc = {
+   .modes = _p097pfg_mode,
+   .bpc = 8,
+   .size = {
+   .width = 147,
+   .height = 196,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 8,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
@@ -259,6 +287,9 @@ static const struct of_device_id innolux_of_match[] = {
{ .compatible = "innolux,p079zca",
  .data = _p079zca_panel_desc
},
+   { .compatible = "innolux,p097pfg",
+ .data = _p097pfg_panel_desc
+   }
 };
 MODULE_DEVICE_TABLE(of, innolux_of_match);
 
-- 
2.7.4



[PATCH v3 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

2017-12-03 Thread Lin Huang
The Innolux P097PFG panel is 9.7" panel with 1536X2048
resolution, it reuse P079ZCA panel driver, so improve
p079ZCA dt-binding to support P097PFG.

Change-Id: I8704914898fe53b734d31fbe646df8aa5fd8b30d
Signed-off-by: Lin Huang 
---
 .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
index d0f5516..8cadd8c 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -1,13 +1,18 @@
 Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
 
 Required properties:
-- compatible: should be "innolux,p079zca"
+- compatible: should be should be one of the following.
+-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel
+-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel
 - reg: DSI virtual channel of the peripheral
-- power-supply: phandle of the regulator that provides the supply voltage
 - enable-gpios: panel enable gpio
 
 Optional properties:
 - backlight: phandle of the backlight device attached to the panel
+- power-supply: phandle of the regulator that provides the supply voltage
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
 
 Example:
 
@@ -16,6 +21,8 @@ Example:
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
+   avdd-supply = <...>;
+   avee-supply = <...>;
backlight = <>;
enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
};
-- 
2.7.4



[PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

2017-12-03 Thread Lin Huang
Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet 
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support 
P097PFG panel in another patch 

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 147 ++
 1 file changed, 105 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..1597744 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,32 @@
 
 #include 
 
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int bpc;
+   struct {
+   unsigned int width;
+   unsigned int height;
+   } size;
+};
+
+struct panel_desc_dsi {
+   struct panel_desc desc;
+
+   unsigned long flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+};
+
 struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+   const struct panel_desc_dsi *dsi_desc;
 
struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;
struct gpio_desc *enable_gpio;
 
bool prepared;
@@ -78,9 +98,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
 
-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;
+   regulator_disable(innolux->avee);
+   regulator_disable(innolux->avdd);
+   regulator_disable(innolux->vddi);
 
innolux->prepared = false;
 
@@ -97,10 +117,18 @@ static int innolux_panel_prepare(struct drm_panel *panel)
 
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
 
-   err = regulator_enable(innolux->supply);
+   err = regulator_enable(innolux->vddi);
if (err < 0)
return err;
 
+   err = regulator_enable(innolux->avdd);
+   if (err < 0)
+   goto disable_vddi;
+
+   err = regulator_enable(innolux->avee);
+   if (err < 0)
+   goto disable_avdd;
+
/* T2: 15ms - 1000ms */
usleep_range(15000, 16000);
 
@@ -134,12 +162,13 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
 
 poweroff:
-   regulator_err = regulator_disable(innolux->supply);
-   if (regulator_err)
-   DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+   regulator_disable(innolux->avee);
+disable_avdd:
+   regulator_disable(innolux->avdd);
+disable_vddi:
+   regulator_disable(innolux->vddi);
+
return err;
 }
 
@@ -164,7 +193,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
 }
 
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -177,15 +206,31 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
 };
 
+static const struct panel_desc_dsi innolux_p079zca_panel_desc = {
+   .desc = {
+   .modes = _p079zca_mode,
+   .bpc = 8,
+   .size = {
+   .width = 120,
+   .height = 160,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   const struct drm_display_mode *m = innolux->dsi_desc->desc.modes;
 
-   mode = drm_mode_duplicate(panel->drm, _mode);
+   mode = drm_mode_duplicate(panel->drm, m);
if (!mode) {
DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ m->hdisplay, m->vdisplay, m->vrefresh);
return -ENOMEM;
}
 
@@ -193,9 +238,11 @@ static int innolux_panel_get_modes(struct drm_panel *panel)
 
drm_mode_probed_add(panel->connector, mode);
 
-   panel->connector->display_info.width_mm = 120;
-   panel->connector->display_info.height_mm = 160;
-   panel->connector->display_info.bpc = 8;
+   panel->connector->display_info.width_mm =
+   innolux->dsi_desc->desc.size.width;
+   

Re: [PATCH net] virtio_net: fix return value check in receive_mergeable()

2017-12-03 Thread Jason Wang



On 2017年12月04日 14:02, wangyunjian wrote:

From: Yunjian Wang 

The function virtqueue_get_buf_ctx() could return NULL, the return
value 'buf' need to be checked with NULL, not value 'ctx'.

Signed-off-by: Yunjian Wang 
---
  drivers/net/virtio_net.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 19a985e..559b215 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -756,7 +756,7 @@ static struct sk_buff *receive_mergeable(struct net_device 
*dev,
int num_skb_frags;
  
  		buf = virtqueue_get_buf_ctx(rq->vq, , );

-   if (unlikely(!ctx)) {
+   if (unlikely(!buf)) {
pr_debug("%s: rx error: %d buffers out of %d missing\n",
 dev->name, num_buf,
 virtio16_to_cpu(vi->vdev,


Hi:

The path looks good but I'm not sure this is a real fix since we add 
data and ctx simultaneously in virtqueue_add_inbuf_ctx().


Any bad result you see without this patch?

Thanks


Re: [PATCH net] virtio_net: fix return value check in receive_mergeable()

2017-12-03 Thread Jason Wang



On 2017年12月04日 14:02, wangyunjian wrote:

From: Yunjian Wang 

The function virtqueue_get_buf_ctx() could return NULL, the return
value 'buf' need to be checked with NULL, not value 'ctx'.

Signed-off-by: Yunjian Wang 
---
  drivers/net/virtio_net.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 19a985e..559b215 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -756,7 +756,7 @@ static struct sk_buff *receive_mergeable(struct net_device 
*dev,
int num_skb_frags;
  
  		buf = virtqueue_get_buf_ctx(rq->vq, , );

-   if (unlikely(!ctx)) {
+   if (unlikely(!buf)) {
pr_debug("%s: rx error: %d buffers out of %d missing\n",
 dev->name, num_buf,
 virtio16_to_cpu(vi->vdev,


Hi:

The path looks good but I'm not sure this is a real fix since we add 
data and ctx simultaneously in virtqueue_add_inbuf_ctx().


Any bad result you see without this patch?

Thanks


[PATCH v6 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-03 Thread Wenyou Yang
The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v6:
 - Remove unnecessary #include .
 - Remove unnecessary comments and extra newline.
 - Add const for some structures.
 - Add the check of the return value from regmap_write().
 - Simplify the calling of __v4l2_ctrl_handler_setup().
 - Add the default format initialization function.
 - Integrate the set_power() and enable/disable the clock into
   one function.

Changes in v5:
 - Squash the driver and MAINTAINERS entry patches to one.
 - Precede the driver patch with the bindings patch.

Changes in v4:
 - Assign 'val' a initial value to avoid warning: 'val' may be
   used uninitialized.
 - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
 - Put the MAINTAINERS change to a separate patch.

Changes in v2:
 - Split off the bindings into a separate patch.
 - Add a new entry to the MAINTAINERS file.

 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |8 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7740.c | 1226 
 4 files changed, 1243 insertions(+)
 create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7a52a66aa991..1de965009b13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
 F: drivers/media/i2c/ov7670.c
 F: Documentation/devicetree/bindings/media/i2c/ov7670.txt
 
+OMNIVISION OV7740 SENSOR DRIVER
+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
 ONENAND FLASH DRIVER
 M: Kyungmin Park 
 L: linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff82915..00b1c4c031d4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
 
+config VIDEO_OV7740
+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
 config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
 obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..42c25277d005
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1226 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * 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.
+ *
+ * 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 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */
+#define REG_HAEC   0x0F/* auto exposure cntrl */
+#define REG_AEC0x10/* auto exposure cntrl */
+
+#define REG_CLK0x11/* Clock 

[PATCH v6 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-03 Thread Wenyou Yang
The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v6:
 - Remove unnecessary #include .
 - Remove unnecessary comments and extra newline.
 - Add const for some structures.
 - Add the check of the return value from regmap_write().
 - Simplify the calling of __v4l2_ctrl_handler_setup().
 - Add the default format initialization function.
 - Integrate the set_power() and enable/disable the clock into
   one function.

Changes in v5:
 - Squash the driver and MAINTAINERS entry patches to one.
 - Precede the driver patch with the bindings patch.

Changes in v4:
 - Assign 'val' a initial value to avoid warning: 'val' may be
   used uninitialized.
 - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
 - Put the MAINTAINERS change to a separate patch.

Changes in v2:
 - Split off the bindings into a separate patch.
 - Add a new entry to the MAINTAINERS file.

 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |8 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7740.c | 1226 
 4 files changed, 1243 insertions(+)
 create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7a52a66aa991..1de965009b13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
 F: drivers/media/i2c/ov7670.c
 F: Documentation/devicetree/bindings/media/i2c/ov7670.txt
 
+OMNIVISION OV7740 SENSOR DRIVER
+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
 ONENAND FLASH DRIVER
 M: Kyungmin Park 
 L: linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff82915..00b1c4c031d4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
 
+config VIDEO_OV7740
+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
 config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
 obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..42c25277d005
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1226 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * 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.
+ *
+ * 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 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */
+#define REG_HAEC   0x0F/* auto exposure cntrl */
+#define REG_AEC0x10/* auto exposure cntrl */
+
+#define REG_CLK0x11/* Clock control */
+#define REG_REG55  0x55/* Clock PLL DIV/PreDiv */
+
+#define REG_REG12  0x12
+
+#define 

[PATCH v6 1/2] media: ov7740: Document device tree bindings

2017-12-03 Thread Wenyou Yang
Add the device tree binding documentation for the ov7740 sensor driver.

Signed-off-by: Wenyou Yang 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
 - Explicitly document the "remote-endpoint" property.

Changes in v2: None

 .../devicetree/bindings/media/i2c/ov7740.txt   | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7740.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
new file mode 100644
index ..af781c3a5f0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
@@ -0,0 +1,47 @@
+* Omnivision OV7740 CMOS image sensor
+
+The Omnivision OV7740 image sensor supports multiple output image
+size, such as VGA, and QVGA, CIF and any size smaller. It also
+supports the RAW RGB and YUV output formats.
+
+The common video interfaces bindings (see video-interfaces.txt) should
+be used to specify link to the image data receiver. The OV7740 device
+node should contain one 'port' child node with an 'endpoint' subnode.
+
+Required Properties:
+- compatible:  "ovti,ov7740".
+- reg: I2C slave address of the sensor.
+- clocks:  Reference to the xvclk input clock.
+- clock-names: "xvclk".
+
+Optional Properties:
+- reset-gpios: Rreference to the GPIO connected to the reset_b pin,
+  if any. Active low with pull-ip resistor.
+- powerdown-gpios: Reference to the GPIO connected to the pwdn pin,
+  if any. Active high with pull-down resistor.
+
+Endpoint node mandatory properties:
+- remote-endpoint: A phandle to the bus receiver's endpoint node.
+
+Example:
+
+   i2c1: i2c@fc028000 {
+   ov7740: camera@21 {
+   compatible = "ovti,ov7740";
+   reg = <0x21>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_sensor_power 
_sensor_reset>;
+   clocks = <>;
+   clock-names = "xvclk";
+   assigned-clocks = <>;
+   assigned-clock-rates = <2400>;
+   reset-gpios = < 43 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = < 44 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
+   };
-- 
2.15.0



[PATCH v6 1/2] media: ov7740: Document device tree bindings

2017-12-03 Thread Wenyou Yang
Add the device tree binding documentation for the ov7740 sensor driver.

Signed-off-by: Wenyou Yang 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
 - Explicitly document the "remote-endpoint" property.

Changes in v2: None

 .../devicetree/bindings/media/i2c/ov7740.txt   | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7740.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
new file mode 100644
index ..af781c3a5f0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
@@ -0,0 +1,47 @@
+* Omnivision OV7740 CMOS image sensor
+
+The Omnivision OV7740 image sensor supports multiple output image
+size, such as VGA, and QVGA, CIF and any size smaller. It also
+supports the RAW RGB and YUV output formats.
+
+The common video interfaces bindings (see video-interfaces.txt) should
+be used to specify link to the image data receiver. The OV7740 device
+node should contain one 'port' child node with an 'endpoint' subnode.
+
+Required Properties:
+- compatible:  "ovti,ov7740".
+- reg: I2C slave address of the sensor.
+- clocks:  Reference to the xvclk input clock.
+- clock-names: "xvclk".
+
+Optional Properties:
+- reset-gpios: Rreference to the GPIO connected to the reset_b pin,
+  if any. Active low with pull-ip resistor.
+- powerdown-gpios: Reference to the GPIO connected to the pwdn pin,
+  if any. Active high with pull-down resistor.
+
+Endpoint node mandatory properties:
+- remote-endpoint: A phandle to the bus receiver's endpoint node.
+
+Example:
+
+   i2c1: i2c@fc028000 {
+   ov7740: camera@21 {
+   compatible = "ovti,ov7740";
+   reg = <0x21>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_sensor_power 
_sensor_reset>;
+   clocks = <>;
+   clock-names = "xvclk";
+   assigned-clocks = <>;
+   assigned-clock-rates = <2400>;
+   reset-gpios = < 43 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = < 44 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
+   };
-- 
2.15.0



[PATCH v6 0/2] media: ov7740: Add a V4L2 sensor-level driver

2017-12-03 Thread Wenyou Yang
Add a Video4Linux2 sensor-level driver for the OmniVision OV7740
VGA camera image sensor.

Changes in v6:
 - Remove unnecessary #include .
 - Remove unnecessary comments and extra newline.
 - Add const for some structures.
 - Add the check of the return value from regmap_write().
 - Simplify the calling of __v4l2_ctrl_handler_setup().
 - Add the default format initialization function.
 - Integrate the set_power() and enable/disable the clock into
   one function.

Changes in v5:
 - Squash the driver and MAINTAINERS entry patches to one.
 - Precede the driver patch with the bindings patch.

Changes in v4:
 - Assign 'val' a initial value to avoid warning: 'val' may be
   used uninitialized.
 - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
 - Explicitly document the "remote-endpoint" property.
 - Put the MAINTAINERS change to a separate patch.

Changes in v2:
 - Split off the bindings into a separate patch.
 - Add a new entry to the MAINTAINERS file.

Wenyou Yang (2):
  media: ov7740: Document device tree bindings
  media: i2c: Add the ov7740 image sensor driver

 .../devicetree/bindings/media/i2c/ov7740.txt   |   47 +
 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |8 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7740.c | 1226 
 5 files changed, 1290 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
 create mode 100644 drivers/media/i2c/ov7740.c

-- 
2.15.0



[PATCH v6 0/2] media: ov7740: Add a V4L2 sensor-level driver

2017-12-03 Thread Wenyou Yang
Add a Video4Linux2 sensor-level driver for the OmniVision OV7740
VGA camera image sensor.

Changes in v6:
 - Remove unnecessary #include .
 - Remove unnecessary comments and extra newline.
 - Add const for some structures.
 - Add the check of the return value from regmap_write().
 - Simplify the calling of __v4l2_ctrl_handler_setup().
 - Add the default format initialization function.
 - Integrate the set_power() and enable/disable the clock into
   one function.

Changes in v5:
 - Squash the driver and MAINTAINERS entry patches to one.
 - Precede the driver patch with the bindings patch.

Changes in v4:
 - Assign 'val' a initial value to avoid warning: 'val' may be
   used uninitialized.
 - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
 - Explicitly document the "remote-endpoint" property.
 - Put the MAINTAINERS change to a separate patch.

Changes in v2:
 - Split off the bindings into a separate patch.
 - Add a new entry to the MAINTAINERS file.

Wenyou Yang (2):
  media: ov7740: Document device tree bindings
  media: i2c: Add the ov7740 image sensor driver

 .../devicetree/bindings/media/i2c/ov7740.txt   |   47 +
 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |8 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7740.c | 1226 
 5 files changed, 1290 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
 create mode 100644 drivers/media/i2c/ov7740.c

-- 
2.15.0



Re: [PATCH v5 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-03 Thread Yang, Wenyou

Hi Sakari,

Sorry for late answer.

Thank you for your review.

On 2017/11/28 20:06, Sakari Ailus wrote:

Hi Wenyou,

Thanks for the patch. Some comments below.

On Tue, Nov 28, 2017 at 01:22:59PM +0800, Wenyou Yang wrote:

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v5:
  - Squash the driver and MAINTAINERS entry patches to one.
  - Precede the driver patch with the bindings patch.

Changes in v4:
  - Assign 'val' a initial value to avoid warning: 'val' may be
used uninitialized.
  - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
  - Put the MAINTAINERS change to a separate patch.

Changes in v2:
  - Split off the bindings into a separate patch.
  - Add a new entry to the MAINTAINERS file.

  MAINTAINERS|8 +
  drivers/media/i2c/Kconfig  |8 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov7740.c | 1220 
  4 files changed, 1237 insertions(+)
  create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..19086a073ae9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
  F:drivers/media/i2c/ov7670.c
  F:Documentation/devicetree/bindings/media/i2c/ov7670.txt
  
+OMNIVISION OV7740 SENSOR DRIVER

+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
  ONENAND FLASH DRIVER
  M:Kyungmin Park 
  L:linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3c6d6428f525..ac484bb82fae 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
  
+config VIDEO_OV7740

+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
  config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
  obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..b2ec015bf3f6
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1220 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * 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.
+ *
+ * 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 

Do you need init.h?

No, will remove it.



+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */
+#define REG_HAEC   0x0F/* auto exposure cntrl */
+#define REG_AEC0x10/* auto exposure cntrl */
+
+#define REG_CLK0x11/* Clock control */
+#define REG_REG55  0x55/* Clock PLL DIV/PreDiv */
+

Re: [PATCH v5 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-03 Thread Yang, Wenyou

Hi Sakari,

Sorry for late answer.

Thank you for your review.

On 2017/11/28 20:06, Sakari Ailus wrote:

Hi Wenyou,

Thanks for the patch. Some comments below.

On Tue, Nov 28, 2017 at 01:22:59PM +0800, Wenyou Yang wrote:

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v5:
  - Squash the driver and MAINTAINERS entry patches to one.
  - Precede the driver patch with the bindings patch.

Changes in v4:
  - Assign 'val' a initial value to avoid warning: 'val' may be
used uninitialized.
  - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
  - Put the MAINTAINERS change to a separate patch.

Changes in v2:
  - Split off the bindings into a separate patch.
  - Add a new entry to the MAINTAINERS file.

  MAINTAINERS|8 +
  drivers/media/i2c/Kconfig  |8 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov7740.c | 1220 
  4 files changed, 1237 insertions(+)
  create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..19086a073ae9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
  F:drivers/media/i2c/ov7670.c
  F:Documentation/devicetree/bindings/media/i2c/ov7670.txt
  
+OMNIVISION OV7740 SENSOR DRIVER

+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
  ONENAND FLASH DRIVER
  M:Kyungmin Park 
  L:linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3c6d6428f525..ac484bb82fae 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
  
+config VIDEO_OV7740

+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
  config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
  obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..b2ec015bf3f6
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1220 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * 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.
+ *
+ * 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 

Do you need init.h?

No, will remove it.



+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */
+#define REG_HAEC   0x0F/* auto exposure cntrl */
+#define REG_AEC0x10/* auto exposure cntrl */
+
+#define REG_CLK0x11/* Clock control */
+#define REG_REG55  0x55/* Clock PLL DIV/PreDiv */
+
+#define REG_REG12  0x12
+
+#define REG_REG13  0x13/* auto/manual AGC, AEC, Write Balance*/

Re: [PATCH] Make FSI a menuconfig to ease disabling it all

2017-12-03 Thread Jeremy Kerr
Hi Vincent,

> No need to get into the submenu to disable all FSI-related config entries

Sounds reasonable to me.

Acked-by: Jeremy Kerr 

Greg: do you want Joel (or me) to manage FSI patches, or would you
prefer to take this directly?

Cheers,


Jeremy


Re: [PATCH] Make FSI a menuconfig to ease disabling it all

2017-12-03 Thread Jeremy Kerr
Hi Vincent,

> No need to get into the submenu to disable all FSI-related config entries

Sounds reasonable to me.

Acked-by: Jeremy Kerr 

Greg: do you want Joel (or me) to manage FSI patches, or would you
prefer to take this directly?

Cheers,


Jeremy


Re: [PATCH 1/3] dt-bindings: Add optional nvmem MAC address bindings to ti,wlink-st

2017-12-03 Thread Marcel Holtmann
Hi David,

> This adds optional nvmem consumer properties to the ti,wlink-st device tree
> bindings to allow specifying the Bluetooth MAC address.
> 
> Signed-off-by: David Lechner 
> ---
> Documentation/devicetree/bindings/net/ti,wilink-st.txt | 4 
> 1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt 
> b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> index 1649c1f..24eb897 100644
> --- a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -32,6 +32,8 @@ Optional properties:
>See ../clocks/clock-bindings.txt for details.
>  - clock-names : Must include the following entry:
>"ext_clock" (External clock provided to the TI combo chip).
> + - nvmem-cells: phandle to nvmem data cell that contains a MAC address
> + - nvmem-cell-names: "mac-address" (required when nvmem-cells is specified)

lets call these “bt-address” since they are not really MAC addresses. They have 
special formatting etc. Also I prefer that the actual format on how they are 
stored is described. See Documentation/devicetree/bindings/net/bluetooth.txt 
for an example.

> Example:
> 
> @@ -43,5 +45,7 @@ Example:
>   enable-gpios = < 7 GPIO_ACTIVE_HIGH>;
>   clocks = <_wl18xx>;
>   clock-names = "ext_clock";
> + nvmem-cells: <_address>
> + nvmem-cell-names "mac-address"
>   };
> };

Regards

Marcel



Re: [PATCH 1/3] dt-bindings: Add optional nvmem MAC address bindings to ti,wlink-st

2017-12-03 Thread Marcel Holtmann
Hi David,

> This adds optional nvmem consumer properties to the ti,wlink-st device tree
> bindings to allow specifying the Bluetooth MAC address.
> 
> Signed-off-by: David Lechner 
> ---
> Documentation/devicetree/bindings/net/ti,wilink-st.txt | 4 
> 1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt 
> b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> index 1649c1f..24eb897 100644
> --- a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -32,6 +32,8 @@ Optional properties:
>See ../clocks/clock-bindings.txt for details.
>  - clock-names : Must include the following entry:
>"ext_clock" (External clock provided to the TI combo chip).
> + - nvmem-cells: phandle to nvmem data cell that contains a MAC address
> + - nvmem-cell-names: "mac-address" (required when nvmem-cells is specified)

lets call these “bt-address” since they are not really MAC addresses. They have 
special formatting etc. Also I prefer that the actual format on how they are 
stored is described. See Documentation/devicetree/bindings/net/bluetooth.txt 
for an example.

> Example:
> 
> @@ -43,5 +45,7 @@ Example:
>   enable-gpios = < 7 GPIO_ACTIVE_HIGH>;
>   clocks = <_wl18xx>;
>   clock-names = "ext_clock";
> + nvmem-cells: <_address>
> + nvmem-cell-names "mac-address"
>   };
> };

Regards

Marcel



Re: [PATCH 3/3] bluetooth: hci_ll: Add optional nvmem MAC address source

2017-12-03 Thread Marcel Holtmann
Hi David,

> This adds an optional nvmem consumer to get a MAC address from an external
> source. The MAC address is then set in the Bluetooth chip after the
> firmware has been loaded.
> 
> This has been tested working with a TI CC2560A chip (in a LEGO MINDSTORMS
> EV3).
> 
> Signed-off-by: David Lechner 
> ---
> drivers/bluetooth/hci_ll.c | 33 +
> 1 file changed, 33 insertions(+)
> 
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 974a788..dd3b5c2 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -53,10 +53,12 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include "hci_uart.h"
> 
> /* Vendor-specific HCI commands */
> +#define HCI_VS_WRITE_BD_ADDR 0xfc06
> #define HCI_VS_UPDATE_UART_HCI_BAUDRATE   0xff36

the first patch should to add support for hdev->set_bdaddr. If the hardware 
supports changing the BD_ADDR, then it should also be exposed via Set Public 
Address mgmt command. For this it is required that the writing of the BD_ADDR 
is non-persistent over power cycles.

> 
> /* HCILL commands */
> @@ -89,6 +91,7 @@ struct ll_device {
>   struct serdev_device *serdev;
>   struct gpio_desc *enable_gpio;
>   struct clk *ext_clk;
> + u8 *bdaddr;

I would prefer if we just store it as bdaddr_t. That will work just fine when 
you created the set_bdaddr helper function that you need for hdev->set_bdaddr 
anyway.

> };
> 
> struct ll_struct {
> @@ -698,6 +701,19 @@ static int ll_setup(struct hci_uart *hu)
>   if (err)
>   return err;
> 
> + /* Set MAC address, if any */
> + if (lldev->bdaddr) {

And here I would really prefer to use bacmp. And example here would be 
btqcomsmd.c on how it is done.

> + struct sk_buff *skb;
> +
> + skb = __hci_cmd_sync(hu->hdev, HCI_VS_WRITE_BD_ADDR, 6,
> +  lldev->bdaddr, HCI_INIT_TIMEOUT);
> + if (IS_ERR(skb))
> + bt_dev_err(hu->hdev, "Failed to set MAC address (%ld)",
> +PTR_ERR(skb));
> + else
> + kfree_skb(skb);
> + }
> +
>   /* Operational speed if any */
>   if (hu->oper_speed)
>   speed = hu->oper_speed;
> @@ -726,6 +742,7 @@ static int hci_ti_probe(struct serdev_device *serdev)
> {
>   struct hci_uart *hu;
>   struct ll_device *lldev;
> + struct nvmem_cell *bdaddr_cell;
>   u32 max_speed = 300;

While this is unrelated to this patch, when I seed the u32 speed and the direct 
use of it in a __hci_cmd_sync, then that is pretty obviously not endian safe. 
You might really want to fix that as well.

>   lldev = devm_kzalloc(>dev, sizeof(struct ll_device), 
> GFP_KERNEL);
> @@ -747,6 +764,22 @@ static int hci_ti_probe(struct serdev_device *serdev)
>   of_property_read_u32(serdev->dev.of_node, "max-speed", _speed);
>   hci_uart_set_speeds(hu, 115200, max_speed);
> 
> + /* optional MAC address from nvram */
> + bdaddr_cell = nvmem_cell_get(>dev, "mac-address”);

I prefer really to use the term “bd-address” like we discussed for the 
btqcomsmd.c driver as well.

> + if (IS_ERR(bdaddr_cell)) {
> + int err = PTR_ERR(bdaddr_cell);
> +
> + if (err != -ENOENT) {
> + if (err != -EPROBE_DEFER)

err != -ENOENT && err != -EPROBE_DEFER

> + dev_err(>dev,
> + "Failed to get \"mac-address\" nvmem 
> cell\n”);

Also this is at most a warning. And more important, I would actually set the 
quirk BDADDR_INVALID here so that the device gets flagged as not having a valid 
address. The Set Public Address mgmt command can then be used from userspace to 
handle that situation.

> + return err;
> + }
> + } else {
> + lldev->bdaddr = nvmem_cell_read(bdaddr_cell, NULL);
> + nvmem_cell_put(bdaddr_cell);
> + }
> +
>   return hci_uart_register_device(hu, );
> }

Regards

Marcel



Re: [PATCH 3/3] bluetooth: hci_ll: Add optional nvmem MAC address source

2017-12-03 Thread Marcel Holtmann
Hi David,

> This adds an optional nvmem consumer to get a MAC address from an external
> source. The MAC address is then set in the Bluetooth chip after the
> firmware has been loaded.
> 
> This has been tested working with a TI CC2560A chip (in a LEGO MINDSTORMS
> EV3).
> 
> Signed-off-by: David Lechner 
> ---
> drivers/bluetooth/hci_ll.c | 33 +
> 1 file changed, 33 insertions(+)
> 
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 974a788..dd3b5c2 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -53,10 +53,12 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include "hci_uart.h"
> 
> /* Vendor-specific HCI commands */
> +#define HCI_VS_WRITE_BD_ADDR 0xfc06
> #define HCI_VS_UPDATE_UART_HCI_BAUDRATE   0xff36

the first patch should to add support for hdev->set_bdaddr. If the hardware 
supports changing the BD_ADDR, then it should also be exposed via Set Public 
Address mgmt command. For this it is required that the writing of the BD_ADDR 
is non-persistent over power cycles.

> 
> /* HCILL commands */
> @@ -89,6 +91,7 @@ struct ll_device {
>   struct serdev_device *serdev;
>   struct gpio_desc *enable_gpio;
>   struct clk *ext_clk;
> + u8 *bdaddr;

I would prefer if we just store it as bdaddr_t. That will work just fine when 
you created the set_bdaddr helper function that you need for hdev->set_bdaddr 
anyway.

> };
> 
> struct ll_struct {
> @@ -698,6 +701,19 @@ static int ll_setup(struct hci_uart *hu)
>   if (err)
>   return err;
> 
> + /* Set MAC address, if any */
> + if (lldev->bdaddr) {

And here I would really prefer to use bacmp. And example here would be 
btqcomsmd.c on how it is done.

> + struct sk_buff *skb;
> +
> + skb = __hci_cmd_sync(hu->hdev, HCI_VS_WRITE_BD_ADDR, 6,
> +  lldev->bdaddr, HCI_INIT_TIMEOUT);
> + if (IS_ERR(skb))
> + bt_dev_err(hu->hdev, "Failed to set MAC address (%ld)",
> +PTR_ERR(skb));
> + else
> + kfree_skb(skb);
> + }
> +
>   /* Operational speed if any */
>   if (hu->oper_speed)
>   speed = hu->oper_speed;
> @@ -726,6 +742,7 @@ static int hci_ti_probe(struct serdev_device *serdev)
> {
>   struct hci_uart *hu;
>   struct ll_device *lldev;
> + struct nvmem_cell *bdaddr_cell;
>   u32 max_speed = 300;

While this is unrelated to this patch, when I seed the u32 speed and the direct 
use of it in a __hci_cmd_sync, then that is pretty obviously not endian safe. 
You might really want to fix that as well.

>   lldev = devm_kzalloc(>dev, sizeof(struct ll_device), 
> GFP_KERNEL);
> @@ -747,6 +764,22 @@ static int hci_ti_probe(struct serdev_device *serdev)
>   of_property_read_u32(serdev->dev.of_node, "max-speed", _speed);
>   hci_uart_set_speeds(hu, 115200, max_speed);
> 
> + /* optional MAC address from nvram */
> + bdaddr_cell = nvmem_cell_get(>dev, "mac-address”);

I prefer really to use the term “bd-address” like we discussed for the 
btqcomsmd.c driver as well.

> + if (IS_ERR(bdaddr_cell)) {
> + int err = PTR_ERR(bdaddr_cell);
> +
> + if (err != -ENOENT) {
> + if (err != -EPROBE_DEFER)

err != -ENOENT && err != -EPROBE_DEFER

> + dev_err(>dev,
> + "Failed to get \"mac-address\" nvmem 
> cell\n”);

Also this is at most a warning. And more important, I would actually set the 
quirk BDADDR_INVALID here so that the device gets flagged as not having a valid 
address. The Set Public Address mgmt command can then be used from userspace to 
handle that situation.

> + return err;
> + }
> + } else {
> + lldev->bdaddr = nvmem_cell_read(bdaddr_cell, NULL);
> + nvmem_cell_put(bdaddr_cell);
> + }
> +
>   return hci_uart_register_device(hu, );
> }

Regards

Marcel



[RFC v2 0/2] Xilinx ZynqMP IPI Mailbox Controller Driver

2017-12-03 Thread Wendy Liang
Introduce mailbox controller driver for ZynqMP IPI(Inter-processor
interrupt) IP core.

There is previous discussion on the DT bindings:
https://patchwork.kernel.org/patch/10012755/

v2:
 - change SPDX-License-Identifier license text style in .c file
 - replace xlnx-ipi-ids with xlnx,ipi-ids

Wendy Liang (2):
  mailbox: ZynqMP IPI mailbox controller
  dt-bindings: mailbox: Add Xilinx IPI Mailbox

 .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt   | 104 
 drivers/mailbox/Kconfig|   8 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/zynqmp-ipi-mailbox.c   | 633 +
 include/linux/mailbox/zynqmp-ipi-message.h |  24 +
 5 files changed, 771 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
 create mode 100644 drivers/mailbox/zynqmp-ipi-mailbox.c
 create mode 100644 include/linux/mailbox/zynqmp-ipi-message.h

-- 
2.7.4



[RFC v2 0/2] Xilinx ZynqMP IPI Mailbox Controller Driver

2017-12-03 Thread Wendy Liang
Introduce mailbox controller driver for ZynqMP IPI(Inter-processor
interrupt) IP core.

There is previous discussion on the DT bindings:
https://patchwork.kernel.org/patch/10012755/

v2:
 - change SPDX-License-Identifier license text style in .c file
 - replace xlnx-ipi-ids with xlnx,ipi-ids

Wendy Liang (2):
  mailbox: ZynqMP IPI mailbox controller
  dt-bindings: mailbox: Add Xilinx IPI Mailbox

 .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt   | 104 
 drivers/mailbox/Kconfig|   8 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/zynqmp-ipi-mailbox.c   | 633 +
 include/linux/mailbox/zynqmp-ipi-message.h |  24 +
 5 files changed, 771 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
 create mode 100644 drivers/mailbox/zynqmp-ipi-mailbox.c
 create mode 100644 include/linux/mailbox/zynqmp-ipi-message.h

-- 
2.7.4



[RFC v2 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox

2017-12-03 Thread Wendy Liang
Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
in ZynqMP SoC used for the communication between various processor
systems.

Signed-off-by: Wendy Liang 
---
 .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt   | 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
new file mode 100644
index 000..5e270a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
@@ -0,0 +1,104 @@
+Xilinx IPI Mailbox Controller
+
+
+The Xilinx IPI(Inter Processor Interrupt) mailbox controller is to manage
+messaging between two Xilinx Zynq UltraScale+ MPSoC IPI agents. Each IPI
+agent owns registers used for notification and buffers for message.
+
+   +-+
+   | Xilinx ZynqMP IPI Controller|
+   +-+
++--+
+ATF| |
+   | |
+   | |
++--+ |
+   | |
+   | |
++--+
++--+
+|  ++   ++ |
+Hardware|  |  IPI Agent |   |  IPI Buffers   | |
+|  |  Registers |   || |
+|  ||   || |
+|  ++   ++ |
+|  |
+| Xilinx IPI Agent Block   |
++--+
+
+
+Controller Device Node:
+===
+Required properties:
+
+- compatible:  Shall be: "xlnx,zynqmp-ipi-mailbox"
+- reg: IPI buffers address ranges
+- reg-names:   Names of the reg resources. It should have:
+   * local_request_region
+ - IPI request msg buffer written by local and read
+   by remote
+   * local_response_region
+ - IPI response msg buffer written by local and read
+   by remote
+   * remote_request_region
+ - IPI request msg buffer written by remote and read
+   by local
+   * remote_response_region
+ - IPI response msg buffer written by remote and read
+   by local
+- #mbox-cells: Shall be 1. It contains:
+   * tx(0) or rx(1) channel
+- xlnx,ipi-ids:Xilinx IPI agent IDs of the two peers of the
+   Xilinx IPI communication channel.
+- interrupt-parent:Phandle for the interrupt controller
+- interrupts:  Interrupt information corresponding to the
+   interrupt-names property.
+
+Optional properties:
+
+- method:  The method of accessing the IPI agent registers.
+   Permitted values are: "smc" and "hvc". Default is
+   "smc".
+
+Example:
+===
+   /* APU<->RPU0 IPI mailbox controller */
+   ipi_mailbox_rpu0: mailbox@ff90400 {
+   compatible = "xlnx,zynqmp-ipi-mailbox";
+   reg = <0x0 0xff990400 0x0 0x20>,
+ <0x0 0xff990420 0x0 0x20>,
+ <0x0 0xff990080 0x0 0x20>,
+ <0x0 0xff9900a0 0x0 0x20>;
+   reg-names = "local_request_region", "local_response_region",
+   "remote_request_region", "remote_response_region";
+   #mbox-cells = <1>;
+   xlnx-ipi-ids = <0 1>;
+   interrupt-parent = <>;
+   interrupts = <0 29 4>;
+   };
+   /* APU<->RPU1 IPI mailbox controller */
+   ipi_mailbox_rpu1: mailbox@ff990440 {
+   compatible = "xlnx,zynqmp-ipi-mailbox";
+   reg = <0x0 0xff990440 0x0 0x20>,
+ <0x0 0xff990460 0x0 0x20>,
+ <0x0 0xff990280 0x0 0x20>,
+ <0x0 0xff9902a0 0x0 0x20>;
+   reg-names = "local_request_region", "local_response_region",
+   "remote_request_region", "remote_response_region";
+   #mbox-cells = <1>;
+   xlnx-ipi-ids = <0 2>;
+   interrupt-parent = <>;
+  

[RFC v2 1/2] mailbox: ZynqMP IPI mailbox controller

2017-12-03 Thread Wendy Liang
This patch is to introduce ZynqMP IPI mailbox controller driver
to use the ZynqMP IPI block as mailboxes.

Signed-off-by: Wendy Liang 
---
 drivers/mailbox/Kconfig|   8 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/zynqmp-ipi-mailbox.c   | 633 +
 include/linux/mailbox/zynqmp-ipi-message.h |  24 ++
 4 files changed, 667 insertions(+)
 create mode 100644 drivers/mailbox/zynqmp-ipi-mailbox.c
 create mode 100644 include/linux/mailbox/zynqmp-ipi-message.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ba2f152..876614a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -171,4 +171,12 @@ config BCM_FLEXRM_MBOX
  Mailbox implementation of the Broadcom FlexRM ring manager,
  which provides access to various offload engines on Broadcom
  SoCs. Say Y here if you want to use the Broadcom FlexRM.
+
+config ZYNQMP_IPI_MBOX
+   tristate "Xilinx ZynqMP IPI Mailbox"
+   depends on ARCH_ZYNQMP && OF
+   help
+ Mailbox implementation for Xilinx ZynqMP IPI. It is used to send
+ notification or short message between processors with Xilinx
+ ZynqMP IPI.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4896f8d..155f72f 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -36,3 +36,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX) += bcm-flexrm-mailbox.o
 obj-$(CONFIG_QCOM_APCS_IPC)+= qcom-apcs-ipc-mailbox.o
 
 obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
+
+obj-$(CONFIG_ZYNQMP_IPI_MBOX)  += zynqmp-ipi-mailbox.o
diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c 
b/drivers/mailbox/zynqmp-ipi-mailbox.c
new file mode 100644
index 000..334f5e1
--- /dev/null
+++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
@@ -0,0 +1,633 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Inter Processor Interrupt(IPI) Mailbox Driver
+ *
+ * Copyright (C) 2017 Xilinx Inc.
+ *
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* IPI agent ID any */
+#define IPI_ID_ANY 0xFFUL
+
+/* indicate if ZynqMP IPI mailbox driver uses SMC calls or HVC calls */
+#define USE_SMC 0
+#define USE_HVC 1
+
+/* Default IPI SMC function IDs */
+#define SMC_IPI_MAILBOX_OPEN0x82001000U
+#define SMC_IPI_MAILBOX_RELEASE 0x82001001U
+#define SMC_IPI_MAILBOX_STATUS_ENQUIRY  0x82001002U
+#define SMC_IPI_MAILBOX_NOTIFY  0x82001003U
+#define SMC_IPI_MAILBOX_ACK 0x82001004U
+#define SMC_IPI_MAILBOX_ENABLE_IRQ  0x82001005U
+#define SMC_IPI_MAILBOX_DISABLE_IRQ 0x82001006U
+
+/* IPI SMC Macros */
+#define IPI_SMC_OPEN_IRQ_MASK  0x0001UL /* IRQ enable bit in IPI
+ * open SMC call
+ */
+#define IPI_SMC_NOTIFY_BLOCK_MASK  0x0001UL /* Flag to indicate if
+ * IPI notification needs
+ * to be blocking.
+ */
+#define IPI_SMC_ENQUIRY_DIRQ_MASK   0x0001UL /* Flag to indicate if
+ * notification interrupt
+ * to be disabled.
+ */
+#define IPI_SMC_ACK_EIRQ_MASK   0x0001UL /* Flag to indicate if
+ * notification interrupt
+ * to be enabled.
+ */
+
+/* IPI mailbox status */
+#define IPI_MB_STATUS_IDLE  0
+#define IPI_MB_STATUS_SEND_PENDING  1
+#define IPI_MB_STATUS_RECV_PENDING  2
+
+#define IPI_MB_CHNL_TX 0 /* IPI mailbox TX channel */
+#define IPI_MB_CHNL_RX 1 /* IPI mailbox RX channel */
+
+/**
+ * struct zynqmp_ipi_mchan - Description of a Xilinx ZynqMP IPI mailbox channel
+ * @is_opened: indicate if the IPI channel is opened
+ * @req_buf: local to remote request buffer start address
+ * @resp_buf: local to remote response buffer start address
+ * @req_buf_size: request buffer size
+ * @resp_buf_size: response buffer size
+ * @chan_type: channel type
+ */
+struct zynqmp_ipi_mchan {
+   int is_opened;
+   void __iomem *req_buf;
+   void __iomem *resp_buf;
+   size_t req_buf_size;
+   size_t resp_buf_size;
+   unsigned int chan_type;
+};
+
+/**
+ * struct zynqmp_ipi_mbox_pdata - Description of a ZynqMP IPI mailbox
+ *platform data.
+ * @dev:  device pointer corresponding to the Xilinx ZynqMP
+ *IPI mailbox
+ * @local_id: local IPI agent ID
+ * 

[RFC v2 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox

2017-12-03 Thread Wendy Liang
Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
in ZynqMP SoC used for the communication between various processor
systems.

Signed-off-by: Wendy Liang 
---
 .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt   | 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
new file mode 100644
index 000..5e270a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
@@ -0,0 +1,104 @@
+Xilinx IPI Mailbox Controller
+
+
+The Xilinx IPI(Inter Processor Interrupt) mailbox controller is to manage
+messaging between two Xilinx Zynq UltraScale+ MPSoC IPI agents. Each IPI
+agent owns registers used for notification and buffers for message.
+
+   +-+
+   | Xilinx ZynqMP IPI Controller|
+   +-+
++--+
+ATF| |
+   | |
+   | |
++--+ |
+   | |
+   | |
++--+
++--+
+|  ++   ++ |
+Hardware|  |  IPI Agent |   |  IPI Buffers   | |
+|  |  Registers |   || |
+|  ||   || |
+|  ++   ++ |
+|  |
+| Xilinx IPI Agent Block   |
++--+
+
+
+Controller Device Node:
+===
+Required properties:
+
+- compatible:  Shall be: "xlnx,zynqmp-ipi-mailbox"
+- reg: IPI buffers address ranges
+- reg-names:   Names of the reg resources. It should have:
+   * local_request_region
+ - IPI request msg buffer written by local and read
+   by remote
+   * local_response_region
+ - IPI response msg buffer written by local and read
+   by remote
+   * remote_request_region
+ - IPI request msg buffer written by remote and read
+   by local
+   * remote_response_region
+ - IPI response msg buffer written by remote and read
+   by local
+- #mbox-cells: Shall be 1. It contains:
+   * tx(0) or rx(1) channel
+- xlnx,ipi-ids:Xilinx IPI agent IDs of the two peers of the
+   Xilinx IPI communication channel.
+- interrupt-parent:Phandle for the interrupt controller
+- interrupts:  Interrupt information corresponding to the
+   interrupt-names property.
+
+Optional properties:
+
+- method:  The method of accessing the IPI agent registers.
+   Permitted values are: "smc" and "hvc". Default is
+   "smc".
+
+Example:
+===
+   /* APU<->RPU0 IPI mailbox controller */
+   ipi_mailbox_rpu0: mailbox@ff90400 {
+   compatible = "xlnx,zynqmp-ipi-mailbox";
+   reg = <0x0 0xff990400 0x0 0x20>,
+ <0x0 0xff990420 0x0 0x20>,
+ <0x0 0xff990080 0x0 0x20>,
+ <0x0 0xff9900a0 0x0 0x20>;
+   reg-names = "local_request_region", "local_response_region",
+   "remote_request_region", "remote_response_region";
+   #mbox-cells = <1>;
+   xlnx-ipi-ids = <0 1>;
+   interrupt-parent = <>;
+   interrupts = <0 29 4>;
+   };
+   /* APU<->RPU1 IPI mailbox controller */
+   ipi_mailbox_rpu1: mailbox@ff990440 {
+   compatible = "xlnx,zynqmp-ipi-mailbox";
+   reg = <0x0 0xff990440 0x0 0x20>,
+ <0x0 0xff990460 0x0 0x20>,
+ <0x0 0xff990280 0x0 0x20>,
+ <0x0 0xff9902a0 0x0 0x20>;
+   reg-names = "local_request_region", "local_response_region",
+   "remote_request_region", "remote_response_region";
+   #mbox-cells = <1>;
+   xlnx-ipi-ids = <0 2>;
+   interrupt-parent = <>;
+   interrupts = <0 

[RFC v2 1/2] mailbox: ZynqMP IPI mailbox controller

2017-12-03 Thread Wendy Liang
This patch is to introduce ZynqMP IPI mailbox controller driver
to use the ZynqMP IPI block as mailboxes.

Signed-off-by: Wendy Liang 
---
 drivers/mailbox/Kconfig|   8 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/zynqmp-ipi-mailbox.c   | 633 +
 include/linux/mailbox/zynqmp-ipi-message.h |  24 ++
 4 files changed, 667 insertions(+)
 create mode 100644 drivers/mailbox/zynqmp-ipi-mailbox.c
 create mode 100644 include/linux/mailbox/zynqmp-ipi-message.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ba2f152..876614a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -171,4 +171,12 @@ config BCM_FLEXRM_MBOX
  Mailbox implementation of the Broadcom FlexRM ring manager,
  which provides access to various offload engines on Broadcom
  SoCs. Say Y here if you want to use the Broadcom FlexRM.
+
+config ZYNQMP_IPI_MBOX
+   tristate "Xilinx ZynqMP IPI Mailbox"
+   depends on ARCH_ZYNQMP && OF
+   help
+ Mailbox implementation for Xilinx ZynqMP IPI. It is used to send
+ notification or short message between processors with Xilinx
+ ZynqMP IPI.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4896f8d..155f72f 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -36,3 +36,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX) += bcm-flexrm-mailbox.o
 obj-$(CONFIG_QCOM_APCS_IPC)+= qcom-apcs-ipc-mailbox.o
 
 obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
+
+obj-$(CONFIG_ZYNQMP_IPI_MBOX)  += zynqmp-ipi-mailbox.o
diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c 
b/drivers/mailbox/zynqmp-ipi-mailbox.c
new file mode 100644
index 000..334f5e1
--- /dev/null
+++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
@@ -0,0 +1,633 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Inter Processor Interrupt(IPI) Mailbox Driver
+ *
+ * Copyright (C) 2017 Xilinx Inc.
+ *
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* IPI agent ID any */
+#define IPI_ID_ANY 0xFFUL
+
+/* indicate if ZynqMP IPI mailbox driver uses SMC calls or HVC calls */
+#define USE_SMC 0
+#define USE_HVC 1
+
+/* Default IPI SMC function IDs */
+#define SMC_IPI_MAILBOX_OPEN0x82001000U
+#define SMC_IPI_MAILBOX_RELEASE 0x82001001U
+#define SMC_IPI_MAILBOX_STATUS_ENQUIRY  0x82001002U
+#define SMC_IPI_MAILBOX_NOTIFY  0x82001003U
+#define SMC_IPI_MAILBOX_ACK 0x82001004U
+#define SMC_IPI_MAILBOX_ENABLE_IRQ  0x82001005U
+#define SMC_IPI_MAILBOX_DISABLE_IRQ 0x82001006U
+
+/* IPI SMC Macros */
+#define IPI_SMC_OPEN_IRQ_MASK  0x0001UL /* IRQ enable bit in IPI
+ * open SMC call
+ */
+#define IPI_SMC_NOTIFY_BLOCK_MASK  0x0001UL /* Flag to indicate if
+ * IPI notification needs
+ * to be blocking.
+ */
+#define IPI_SMC_ENQUIRY_DIRQ_MASK   0x0001UL /* Flag to indicate if
+ * notification interrupt
+ * to be disabled.
+ */
+#define IPI_SMC_ACK_EIRQ_MASK   0x0001UL /* Flag to indicate if
+ * notification interrupt
+ * to be enabled.
+ */
+
+/* IPI mailbox status */
+#define IPI_MB_STATUS_IDLE  0
+#define IPI_MB_STATUS_SEND_PENDING  1
+#define IPI_MB_STATUS_RECV_PENDING  2
+
+#define IPI_MB_CHNL_TX 0 /* IPI mailbox TX channel */
+#define IPI_MB_CHNL_RX 1 /* IPI mailbox RX channel */
+
+/**
+ * struct zynqmp_ipi_mchan - Description of a Xilinx ZynqMP IPI mailbox channel
+ * @is_opened: indicate if the IPI channel is opened
+ * @req_buf: local to remote request buffer start address
+ * @resp_buf: local to remote response buffer start address
+ * @req_buf_size: request buffer size
+ * @resp_buf_size: response buffer size
+ * @chan_type: channel type
+ */
+struct zynqmp_ipi_mchan {
+   int is_opened;
+   void __iomem *req_buf;
+   void __iomem *resp_buf;
+   size_t req_buf_size;
+   size_t resp_buf_size;
+   unsigned int chan_type;
+};
+
+/**
+ * struct zynqmp_ipi_mbox_pdata - Description of a ZynqMP IPI mailbox
+ *platform data.
+ * @dev:  device pointer corresponding to the Xilinx ZynqMP
+ *IPI mailbox
+ * @local_id: local IPI agent ID
+ * @remote_id:   

Re: linux-next: build warning after merge of the net-next tree

2017-12-03 Thread Heiner Kallweit
Am 04.12.2017 um 01:02 schrieb Stephen Rothwell:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> drivers/net/phy/broadcom.c:391:12: warning: 'bcm5482_read_status' defined but 
> not used [-Wunused-function]
>  static int bcm5482_read_status(struct phy_device *phydev)
> ^
> drivers/net/phy/broadcom.c:411:12: warning: 'bcm5481_config_aneg' defined but 
> not used [-Wunused-function]
>  static int bcm5481_config_aneg(struct phy_device *phydev)
> ^
> 
> Introduced by commit
> 
>   80274abafc60 ("net: phy: remove generic settings for callbacks config_aneg 
> and read_status from drivers")
> 
This issue has been addressed addressed already, see this patch:
https://marc.info/?l=linux-netdev=151220825402398=2

Rgds, Heiner


Re: linux-next: build warning after merge of the net-next tree

2017-12-03 Thread Heiner Kallweit
Am 04.12.2017 um 01:02 schrieb Stephen Rothwell:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> drivers/net/phy/broadcom.c:391:12: warning: 'bcm5482_read_status' defined but 
> not used [-Wunused-function]
>  static int bcm5482_read_status(struct phy_device *phydev)
> ^
> drivers/net/phy/broadcom.c:411:12: warning: 'bcm5481_config_aneg' defined but 
> not used [-Wunused-function]
>  static int bcm5481_config_aneg(struct phy_device *phydev)
> ^
> 
> Introduced by commit
> 
>   80274abafc60 ("net: phy: remove generic settings for callbacks config_aneg 
> and read_status from drivers")
> 
This issue has been addressed addressed already, see this patch:
https://marc.info/?l=linux-netdev=151220825402398=2

Rgds, Heiner


Re: [PATCH 2/3] bluetooth: hci_ll: add constant for vendor-specific command

2017-12-03 Thread Marcel Holtmann
Hi David,

> This adds a #define for the vendor-specific HCI command to set the
> baudrate instead of using the bare 0xff36 multiple times.
> 
> Signed-off-by: David Lechner 
> ---
> drivers/bluetooth/hci_ll.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel



Re: [PATCH 2/3] bluetooth: hci_ll: add constant for vendor-specific command

2017-12-03 Thread Marcel Holtmann
Hi David,

> This adds a #define for the vendor-specific HCI command to set the
> baudrate instead of using the bare 0xff36 multiple times.
> 
> Signed-off-by: David Lechner 
> ---
> drivers/bluetooth/hci_ll.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel



Re: [PATCH 0/4] Fix use after free in HPT resizing code and related minor improvements

2017-12-03 Thread David Gibson
On Wed, Nov 29, 2017 at 11:38:22AM -0500, Serhii Popovych wrote:
> It is possible to trigger use after free during HPT resize
> causing host kernel to crash. More details and analysis of
> the problem can be found in change with corresponding subject
> (KVM: PPC: Book3S HV: Fix use after free in case of multiple
> resize requests).
> 
> We need some changes to prepare for the fix, especially
> make ->error in HPT resize instance single point for
> tracking allocation state, improve kvmppc_allocate_hpt()
> and kvmppc_free_hpt() so they can be used more safely.
> 
> See individual commit description message to get more
> information on changes presented.

I spoke with Paul Mackerras about these patches on IRC today.  We want
this as a fix, ASAP, in 4.15.  However, he's uncomfortable with
pushing some of extra cleanups which aren't necessary for the bug fix
this late for 4.15, and was having trouble following what was the core
of the fix.  He was also nervous about the addition of more BUG_ON()s.

To avoid the round trip to Ukraine time and back, I've made revised
versions of patches 1 & 3 which should apply standalone, replaced the
BUG_ON()s with WARN_ON()s and revised the commit messages to better
explain the crucial part of the fix.

However, I've run out of time to test them.

Serhii,  I'll send you my revised patches shortly.  Can you please
test them and repost.  Then you can rebase patches 2 & 4 from this
series on top of the revised patches and post those separately (as a
cleanup with less urgency than the actual fix).

A couple of people have also suggested CCing k...@vger.kernel.org on
the next round in addition to the lists already included.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [PATCH 0/4] Fix use after free in HPT resizing code and related minor improvements

2017-12-03 Thread David Gibson
On Wed, Nov 29, 2017 at 11:38:22AM -0500, Serhii Popovych wrote:
> It is possible to trigger use after free during HPT resize
> causing host kernel to crash. More details and analysis of
> the problem can be found in change with corresponding subject
> (KVM: PPC: Book3S HV: Fix use after free in case of multiple
> resize requests).
> 
> We need some changes to prepare for the fix, especially
> make ->error in HPT resize instance single point for
> tracking allocation state, improve kvmppc_allocate_hpt()
> and kvmppc_free_hpt() so they can be used more safely.
> 
> See individual commit description message to get more
> information on changes presented.

I spoke with Paul Mackerras about these patches on IRC today.  We want
this as a fix, ASAP, in 4.15.  However, he's uncomfortable with
pushing some of extra cleanups which aren't necessary for the bug fix
this late for 4.15, and was having trouble following what was the core
of the fix.  He was also nervous about the addition of more BUG_ON()s.

To avoid the round trip to Ukraine time and back, I've made revised
versions of patches 1 & 3 which should apply standalone, replaced the
BUG_ON()s with WARN_ON()s and revised the commit messages to better
explain the crucial part of the fix.

However, I've run out of time to test them.

Serhii,  I'll send you my revised patches shortly.  Can you please
test them and repost.  Then you can rebase patches 2 & 4 from this
series on top of the revised patches and post those separately (as a
cleanup with less urgency than the actual fix).

A couple of people have also suggested CCing k...@vger.kernel.org on
the next round in addition to the lists already included.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [PATCH v2 00/15] NTB: Add full multi-port API support to the test drivers

2017-12-03 Thread Serge Semin
On Sun, Dec 03, 2017 at 09:54:58PM -0700, Logan Gunthorpe  
wrote:
> 
> 
> On 03/12/17 12:17 PM, Serge Semin wrote:
> > The multi-port NTB API was introduced in kernel 4.13 as well as the
> > first driver for the true multi-port devices of IDT PCIe-switches
> > series. But the test drivers still were left almost unchanged. Yes,
> > they didn't fail being used with new NTB API, but they only worked
> > with two-ports NTB devices. This patchset is intended to fix the
> > issue, by amending the NTB test drivers and script so they would be
> > fully compatible with multi-port NTB API.
> > 
> > Additionally I found a few NTB subsystem issues while developing the
> > submitted patches. So they are also fixed in this patchset.
> 
> 
> Did anything change since the last posting of these patches? I took a
> very brief look and did not see anything changed.
> 

Nothing has changed.

> Logan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-ntb" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-ntb+unsubscr...@googlegroups.com.
> To post to this group, send email to linux-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/linux-ntb/681f296e-136c-e907-c520-a2035897833a%40deltatee.com.
> For more options, visit https://groups.google.com/d/optout.


Re: [PATCH v2 00/15] NTB: Add full multi-port API support to the test drivers

2017-12-03 Thread Serge Semin
On Sun, Dec 03, 2017 at 09:54:58PM -0700, Logan Gunthorpe  
wrote:
> 
> 
> On 03/12/17 12:17 PM, Serge Semin wrote:
> > The multi-port NTB API was introduced in kernel 4.13 as well as the
> > first driver for the true multi-port devices of IDT PCIe-switches
> > series. But the test drivers still were left almost unchanged. Yes,
> > they didn't fail being used with new NTB API, but they only worked
> > with two-ports NTB devices. This patchset is intended to fix the
> > issue, by amending the NTB test drivers and script so they would be
> > fully compatible with multi-port NTB API.
> > 
> > Additionally I found a few NTB subsystem issues while developing the
> > submitted patches. So they are also fixed in this patchset.
> 
> 
> Did anything change since the last posting of these patches? I took a
> very brief look and did not see anything changed.
> 

Nothing has changed.

> Logan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-ntb" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-ntb+unsubscr...@googlegroups.com.
> To post to this group, send email to linux-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/linux-ntb/681f296e-136c-e907-c520-a2035897833a%40deltatee.com.
> For more options, visit https://groups.google.com/d/optout.


[PATCH net] virtio_net: fix return value check in receive_mergeable()

2017-12-03 Thread wangyunjian
From: Yunjian Wang 

The function virtqueue_get_buf_ctx() could return NULL, the return
value 'buf' need to be checked with NULL, not value 'ctx'.

Signed-off-by: Yunjian Wang 
---
 drivers/net/virtio_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 19a985e..559b215 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -756,7 +756,7 @@ static struct sk_buff *receive_mergeable(struct net_device 
*dev,
int num_skb_frags;
 
buf = virtqueue_get_buf_ctx(rq->vq, , );
-   if (unlikely(!ctx)) {
+   if (unlikely(!buf)) {
pr_debug("%s: rx error: %d buffers out of %d missing\n",
 dev->name, num_buf,
 virtio16_to_cpu(vi->vdev,
-- 
1.8.3.1




[PATCH net] virtio_net: fix return value check in receive_mergeable()

2017-12-03 Thread wangyunjian
From: Yunjian Wang 

The function virtqueue_get_buf_ctx() could return NULL, the return
value 'buf' need to be checked with NULL, not value 'ctx'.

Signed-off-by: Yunjian Wang 
---
 drivers/net/virtio_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 19a985e..559b215 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -756,7 +756,7 @@ static struct sk_buff *receive_mergeable(struct net_device 
*dev,
int num_skb_frags;
 
buf = virtqueue_get_buf_ctx(rq->vq, , );
-   if (unlikely(!ctx)) {
+   if (unlikely(!buf)) {
pr_debug("%s: rx error: %d buffers out of %d missing\n",
 dev->name, num_buf,
 virtio16_to_cpu(vi->vdev,
-- 
1.8.3.1




[PATCH 3/3] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC

2017-12-03 Thread Yixun Lan
From: Jian Hu 

Add PWM DT info for the Amlogic's Meson-Axg SoC.

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 120 +
 1 file changed, 120 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 92f65eec3e18..f7f228701df1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -177,6 +177,24 @@
clock-names = "clk_i2c";
};
 
+   pwm_ab: pwm@1b000 {
+   compatible = "amlogic,meson-axg-ee-pwm";
+   reg = <0x0 0x1b000 0x0 0x20>;
+   #pwm-cells = <3>;
+   clocks = <>, <>;
+   clock-names = "clkin0", "clkin1";
+   status = "disabled";
+   };
+
+   pwm_cd: pwm@1a000 {
+   compatible = "amlogic,meson-axg-ee-pwm";
+   reg = <0x0 0x1a000 0x0 0x20>;
+   #pwm-cells = <3>;
+   clocks = <>, <>;
+   clock-names = "clkin0", "clkin1";
+   status = "disabled";
+   };
+
uart_A: serial@24000 {
compatible = "amlogic,meson-gx-uart", 
"amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -368,6 +386,90 @@
function = "i2c3";
};
};
+
+   pwm_a_a_pins: pwm_a_a {
+   mux {
+   groups = "pwm_a_a";
+   function = "pwm_a";
+   };
+   };
+
+   pwm_a_x18_pins: pwm_a_x18 {
+   mux {
+   groups = "pwm_a_x18";
+   function = "pwm_a";
+   };
+   };
+
+   pwm_a_x20_pins: pwm_a_x20 {
+   mux {
+   groups = "pwm_a_x20";
+   function = "pwm_a";
+   };
+   };
+
+   pwm_a_z_pins: pwm_a_z {
+   mux {
+   groups = "pwm_a_z";
+   function = "pwm_a";
+   };
+   };
+
+   pwm_b_a_pins: pwm_b_a {
+   mux {
+   groups = "pwm_b_a";
+   function = "pwm_b";
+   };
+   };
+
+   pwm_b_x_pins: pwm_b_x {
+   mux {
+   groups = "pwm_b_x";
+   function = "pwm_b";
+   };
+   };
+
+   pwm_b_z_pins: pwm_b_z {
+   mux {
+   groups = "pwm_b_z";
+   function = "pwm_b";
+   };
+   };
+
+   pwm_c_a_pins: pwm_c_a {
+   mux {
+   groups = "pwm_c_a";
+   function = "pwm_c";
+   };
+   };
+
+   pwm_c_x10_pins: pwm_c_x10 {
+   mux {
+   groups = "pwm_c_x10";
+   function = "pwm_c";
+   };
+   };
+
+   pwm_c_x17_pins: pwm_c_x17 {
+   mux {
+   groups = "pwm_c_x17";
+   function = "pwm_c";
+

[PATCH 2/3] pwm: meson: add clock source configuratin for Meson-AXG

2017-12-03 Thread Yixun Lan
From: Jian Hu 

For PWM controller in the Meson-AXG SoC, the EE domain and
AO domain have different clock source. This patch try to describe
them in the DT compatible data.

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 drivers/pwm/pwm-meson.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 1f44b288af57..dcacc5c6ac1e 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -421,6 +421,24 @@ static const struct meson_pwm_data pwm_gxbb_ao_data = {
.num_parents = ARRAY_SIZE(pwm_gxbb_ao_parent_names),
 };
 
+static const char * const pwm_axg_ee_parent_names[] = {
+   "xtal", "fclk_div5", "fclk_div4", "fclk_div3"
+};
+
+static const struct meson_pwm_data pwm_axg_ee_data = {
+   .parent_names = pwm_axg_ee_parent_names,
+   .num_parents = ARRAY_SIZE(pwm_axg_ee_parent_names),
+};
+
+static const char * const pwm_axg_ao_parent_names[] = {
+   "aoclk81", "xtal", "fclk_div4", "fclk_div5"
+};
+
+static const struct meson_pwm_data pwm_axg_ao_data = {
+   .parent_names = pwm_axg_ao_parent_names,
+   .num_parents = ARRAY_SIZE(pwm_axg_ao_parent_names),
+};
+
 static const struct of_device_id meson_pwm_matches[] = {
{
.compatible = "amlogic,meson8b-pwm",
@@ -434,6 +452,14 @@ static const struct of_device_id meson_pwm_matches[] = {
.compatible = "amlogic,meson-gxbb-ao-pwm",
.data = _gxbb_ao_data
},
+   {
+   .compatible = "amlogic,meson-axg-ee-pwm",
+   .data = _axg_ee_data
+   },
+   {
+   .compatible = "amlogic,meson-axg-ao-pwm",
+   .data = _axg_ao_data
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, meson_pwm_matches);
-- 
2.15.0



[PATCH 3/3] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC

2017-12-03 Thread Yixun Lan
From: Jian Hu 

Add PWM DT info for the Amlogic's Meson-Axg SoC.

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 120 +
 1 file changed, 120 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 92f65eec3e18..f7f228701df1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -177,6 +177,24 @@
clock-names = "clk_i2c";
};
 
+   pwm_ab: pwm@1b000 {
+   compatible = "amlogic,meson-axg-ee-pwm";
+   reg = <0x0 0x1b000 0x0 0x20>;
+   #pwm-cells = <3>;
+   clocks = <>, <>;
+   clock-names = "clkin0", "clkin1";
+   status = "disabled";
+   };
+
+   pwm_cd: pwm@1a000 {
+   compatible = "amlogic,meson-axg-ee-pwm";
+   reg = <0x0 0x1a000 0x0 0x20>;
+   #pwm-cells = <3>;
+   clocks = <>, <>;
+   clock-names = "clkin0", "clkin1";
+   status = "disabled";
+   };
+
uart_A: serial@24000 {
compatible = "amlogic,meson-gx-uart", 
"amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -368,6 +386,90 @@
function = "i2c3";
};
};
+
+   pwm_a_a_pins: pwm_a_a {
+   mux {
+   groups = "pwm_a_a";
+   function = "pwm_a";
+   };
+   };
+
+   pwm_a_x18_pins: pwm_a_x18 {
+   mux {
+   groups = "pwm_a_x18";
+   function = "pwm_a";
+   };
+   };
+
+   pwm_a_x20_pins: pwm_a_x20 {
+   mux {
+   groups = "pwm_a_x20";
+   function = "pwm_a";
+   };
+   };
+
+   pwm_a_z_pins: pwm_a_z {
+   mux {
+   groups = "pwm_a_z";
+   function = "pwm_a";
+   };
+   };
+
+   pwm_b_a_pins: pwm_b_a {
+   mux {
+   groups = "pwm_b_a";
+   function = "pwm_b";
+   };
+   };
+
+   pwm_b_x_pins: pwm_b_x {
+   mux {
+   groups = "pwm_b_x";
+   function = "pwm_b";
+   };
+   };
+
+   pwm_b_z_pins: pwm_b_z {
+   mux {
+   groups = "pwm_b_z";
+   function = "pwm_b";
+   };
+   };
+
+   pwm_c_a_pins: pwm_c_a {
+   mux {
+   groups = "pwm_c_a";
+   function = "pwm_c";
+   };
+   };
+
+   pwm_c_x10_pins: pwm_c_x10 {
+   mux {
+   groups = "pwm_c_x10";
+   function = "pwm_c";
+   };
+   };
+
+   pwm_c_x17_pins: pwm_c_x17 {
+   mux {
+   groups = "pwm_c_x17";
+   function = "pwm_c";
+   };
+  

[PATCH 2/3] pwm: meson: add clock source configuratin for Meson-AXG

2017-12-03 Thread Yixun Lan
From: Jian Hu 

For PWM controller in the Meson-AXG SoC, the EE domain and
AO domain have different clock source. This patch try to describe
them in the DT compatible data.

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 drivers/pwm/pwm-meson.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 1f44b288af57..dcacc5c6ac1e 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -421,6 +421,24 @@ static const struct meson_pwm_data pwm_gxbb_ao_data = {
.num_parents = ARRAY_SIZE(pwm_gxbb_ao_parent_names),
 };
 
+static const char * const pwm_axg_ee_parent_names[] = {
+   "xtal", "fclk_div5", "fclk_div4", "fclk_div3"
+};
+
+static const struct meson_pwm_data pwm_axg_ee_data = {
+   .parent_names = pwm_axg_ee_parent_names,
+   .num_parents = ARRAY_SIZE(pwm_axg_ee_parent_names),
+};
+
+static const char * const pwm_axg_ao_parent_names[] = {
+   "aoclk81", "xtal", "fclk_div4", "fclk_div5"
+};
+
+static const struct meson_pwm_data pwm_axg_ao_data = {
+   .parent_names = pwm_axg_ao_parent_names,
+   .num_parents = ARRAY_SIZE(pwm_axg_ao_parent_names),
+};
+
 static const struct of_device_id meson_pwm_matches[] = {
{
.compatible = "amlogic,meson8b-pwm",
@@ -434,6 +452,14 @@ static const struct of_device_id meson_pwm_matches[] = {
.compatible = "amlogic,meson-gxbb-ao-pwm",
.data = _gxbb_ao_data
},
+   {
+   .compatible = "amlogic,meson-axg-ee-pwm",
+   .data = _axg_ee_data
+   },
+   {
+   .compatible = "amlogic,meson-axg-ao-pwm",
+   .data = _axg_ao_data
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, meson_pwm_matches);
-- 
2.15.0



[PATCH 1/3] dt-bindings: pwm: update bindings for the Meson-AXG

2017-12-03 Thread Yixun Lan
From: Jian Hu 

Update the doc to explicitly support Meson-AXG

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 Documentation/devicetree/bindings/pwm/pwm-meson.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-meson.txt 
b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
index 1ee81321c35e..1fa3f7182133 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-meson.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
@@ -5,6 +5,8 @@ Required properties:
 - compatible: Shall contain "amlogic,meson8b-pwm"
  or "amlogic,meson-gxbb-pwm"
  or "amlogic,meson-gxbb-ao-pwm"
+ or "amlogic,meson-axg-ee-pwm"
+ or "amlogic,meson-axg-ao-pwm"
 - #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
   the cells format.
 
-- 
2.15.0



[PATCH 1/3] dt-bindings: pwm: update bindings for the Meson-AXG

2017-12-03 Thread Yixun Lan
From: Jian Hu 

Update the doc to explicitly support Meson-AXG

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 Documentation/devicetree/bindings/pwm/pwm-meson.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-meson.txt 
b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
index 1ee81321c35e..1fa3f7182133 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-meson.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
@@ -5,6 +5,8 @@ Required properties:
 - compatible: Shall contain "amlogic,meson8b-pwm"
  or "amlogic,meson-gxbb-pwm"
  or "amlogic,meson-gxbb-ao-pwm"
+ or "amlogic,meson-axg-ee-pwm"
+ or "amlogic,meson-axg-ao-pwm"
 - #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
   the cells format.
 
-- 
2.15.0



[PATCH 0/3] pwm: meson-axg: add pwm controller driver

2017-12-03 Thread Yixun Lan
This patch series try to add PWM controller driver for the 
Amlogic's Meson-AXG SoC. Update the Clock sources, pin DT.

Jian Hu (3):
  dt-bindings: pwm: update bindings for the Meson-AXG
  pwm: meson: add clock source configuratin for Meson-AXG
  ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC

 .../devicetree/bindings/pwm/pwm-meson.txt  |   2 +
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 120 +
 drivers/pwm/pwm-meson.c|  26 +
 3 files changed, 148 insertions(+)

-- 
2.15.0



[PATCH 0/3] pwm: meson-axg: add pwm controller driver

2017-12-03 Thread Yixun Lan
This patch series try to add PWM controller driver for the 
Amlogic's Meson-AXG SoC. Update the Clock sources, pin DT.

Jian Hu (3):
  dt-bindings: pwm: update bindings for the Meson-AXG
  pwm: meson: add clock source configuratin for Meson-AXG
  ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC

 .../devicetree/bindings/pwm/pwm-meson.txt  |   2 +
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 120 +
 drivers/pwm/pwm-meson.c|  26 +
 3 files changed, 148 insertions(+)

-- 
2.15.0



Re: [PATCH] riscv/ftrace: Add basic support

2017-12-03 Thread Alan Kao
On Thu, Nov 30, 2017 at 03:24:21PM -0500, Steven Rostedt wrote:
> On Thu, 30 Nov 2017 16:53:35 +0800
> Alan Kao  wrote:
> 
> > This patch contains basic ftrace support for RV64I platform.
> > Specifically, function tracer (HAVE_FUNCTION_TRACER), function graph
> > tracer (HAVE_FUNCTION_GRAPH_TRACER), and a frame pointer test
> > (HAVE_FUNCTION_GRAPH_FP_TEST) are implemented following the
> > instructions in Documentation/trace/ftrace-design.txt.
> 
> Hmm, that document is somewhat out of date. Hopefully it was good
> enough. I'm going to need some time to update it.
> 
> > 
> > Note that the functions in both ftrace.c and setup.c should not be
> > hooked with the compiler's -pg option: to prevent infinite self-
> > referencing for the former, and to ignore early setup stuff for the latter.
> 
> I'm curious to what is in setup.c that ftrace uses.

In the scenario for some embedded systems, the __init prefix does not give 
us the notrace feature without the MODULE config.  Therefore, all functions 
would have been hooked with the _mcount trampoline if the -pg flag was not 
specifically disabled.

And a terrible result would have happened after function setup_vm called
_mcount.  As _mcount compared the value of ftrace_trace_function and 
the position of ftrace_stub, it crashed the kernel because one of them 
was a physical address while the other was a virtual address but
actually they pointed to the same.

Adding notrace to setup_vm can solve the described issue, but it might be 
redundant once the MODULE config becomes stable and default on most 
platforms. To be honest, nobody really needs those init procedures to be
ftrace-able.

> 
> > 
> > Signed-off-by: Alan Kao 
> > ---
> >  arch/riscv/Kconfig  |   8 +++
> >  arch/riscv/include/asm/Kbuild   |   1 -
> >  arch/riscv/include/asm/ftrace.h |  23 +++
> >  arch/riscv/kernel/Makefile  |   7 ++
> >  arch/riscv/kernel/ftrace.c  |  56 
> >  arch/riscv/kernel/mcount.S  | 139 
> > 
> >  6 files changed, 233 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/riscv/include/asm/ftrace.h
> >  create mode 100644 arch/riscv/kernel/ftrace.c
> >  create mode 100644 arch/riscv/kernel/mcount.S
> > 
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 2e15e85c8f7e..07c3df0919b7 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -60,6 +60,12 @@ config PAGE_OFFSET
> >  config STACKTRACE_SUPPORT
> > def_bool y
> >  
> > +config TRACE_IRQFLAGS_SUPPORT
> > +   def_bool y
> > +
> > +config LOCKDEP_SUPPORT
> > +   def_bool y
> 
> Hmm, not sure the above is needed for function tracing.
>

FTRACE depends on TRACING_SUPPORT, and TRACING_SUPPORT depends on
TRACE_IRQFLAGS_SUPPORT. But LOCKDEP_SUPPORT is not actually needed
for any of the ftrace features implemented in this patch.

The LOCKDEP_SUPPORT will be removed in the next version.

> > +
> >  config RWSEM_GENERIC_SPINLOCK
> > def_bool y
> >  
> > @@ -112,6 +118,8 @@ config ARCH_RV64I
> > bool "RV64I"
> > select CPU_SUPPORTS_64BIT_KERNEL
> > select 64BIT
> > +   select HAVE_FUNCTION_TRACER
> > +   select HAVE_FUNCTION_GRAPH_TRACER
> >  
> >  endchoice
> >  
> > diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
> > index 18158be62a2b..680301bfbc4b 100644
> > --- a/arch/riscv/include/asm/Kbuild
> > +++ b/arch/riscv/include/asm/Kbuild
> > @@ -12,7 +12,6 @@ generic-y += errno.h
> >  generic-y += exec.h
> >  generic-y += fb.h
> >  generic-y += fcntl.h
> > -generic-y += ftrace.h
> >  generic-y += futex.h
> >  generic-y += hardirq.h
> >  generic-y += hash.h
> > diff --git a/arch/riscv/include/asm/ftrace.h 
> > b/arch/riscv/include/asm/ftrace.h
> > new file mode 100644
> > index ..38beadb07ad5
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/ftrace.h
> > @@ -0,0 +1,23 @@
> > +/*
> > + * Copyright (C) 2017 Andes Technology Corporation
> > + *
> > + * 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.
> > + *
> > + * 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 .
> > + */
> > +
> > +/*
> > + * The graph frame test is not possible if CONFIG_FRAME_POINTER is not 
> > enabled.
> > + * Check arch/riscv/kernel/mcount.S for detail.
> > + */
> > +#if defined(CONFIG_FUNCTION_GRAPH_TRACER) && defined(CONFIG_FRAME_POINTER)
> > +#define HAVE_FUNCTION_GRAPH_FP_TEST
> > +#endif
> > diff --git a/arch/riscv/kernel/Makefile 

Re: [PATCH] riscv/ftrace: Add basic support

2017-12-03 Thread Alan Kao
On Thu, Nov 30, 2017 at 03:24:21PM -0500, Steven Rostedt wrote:
> On Thu, 30 Nov 2017 16:53:35 +0800
> Alan Kao  wrote:
> 
> > This patch contains basic ftrace support for RV64I platform.
> > Specifically, function tracer (HAVE_FUNCTION_TRACER), function graph
> > tracer (HAVE_FUNCTION_GRAPH_TRACER), and a frame pointer test
> > (HAVE_FUNCTION_GRAPH_FP_TEST) are implemented following the
> > instructions in Documentation/trace/ftrace-design.txt.
> 
> Hmm, that document is somewhat out of date. Hopefully it was good
> enough. I'm going to need some time to update it.
> 
> > 
> > Note that the functions in both ftrace.c and setup.c should not be
> > hooked with the compiler's -pg option: to prevent infinite self-
> > referencing for the former, and to ignore early setup stuff for the latter.
> 
> I'm curious to what is in setup.c that ftrace uses.

In the scenario for some embedded systems, the __init prefix does not give 
us the notrace feature without the MODULE config.  Therefore, all functions 
would have been hooked with the _mcount trampoline if the -pg flag was not 
specifically disabled.

And a terrible result would have happened after function setup_vm called
_mcount.  As _mcount compared the value of ftrace_trace_function and 
the position of ftrace_stub, it crashed the kernel because one of them 
was a physical address while the other was a virtual address but
actually they pointed to the same.

Adding notrace to setup_vm can solve the described issue, but it might be 
redundant once the MODULE config becomes stable and default on most 
platforms. To be honest, nobody really needs those init procedures to be
ftrace-able.

> 
> > 
> > Signed-off-by: Alan Kao 
> > ---
> >  arch/riscv/Kconfig  |   8 +++
> >  arch/riscv/include/asm/Kbuild   |   1 -
> >  arch/riscv/include/asm/ftrace.h |  23 +++
> >  arch/riscv/kernel/Makefile  |   7 ++
> >  arch/riscv/kernel/ftrace.c  |  56 
> >  arch/riscv/kernel/mcount.S  | 139 
> > 
> >  6 files changed, 233 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/riscv/include/asm/ftrace.h
> >  create mode 100644 arch/riscv/kernel/ftrace.c
> >  create mode 100644 arch/riscv/kernel/mcount.S
> > 
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 2e15e85c8f7e..07c3df0919b7 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -60,6 +60,12 @@ config PAGE_OFFSET
> >  config STACKTRACE_SUPPORT
> > def_bool y
> >  
> > +config TRACE_IRQFLAGS_SUPPORT
> > +   def_bool y
> > +
> > +config LOCKDEP_SUPPORT
> > +   def_bool y
> 
> Hmm, not sure the above is needed for function tracing.
>

FTRACE depends on TRACING_SUPPORT, and TRACING_SUPPORT depends on
TRACE_IRQFLAGS_SUPPORT. But LOCKDEP_SUPPORT is not actually needed
for any of the ftrace features implemented in this patch.

The LOCKDEP_SUPPORT will be removed in the next version.

> > +
> >  config RWSEM_GENERIC_SPINLOCK
> > def_bool y
> >  
> > @@ -112,6 +118,8 @@ config ARCH_RV64I
> > bool "RV64I"
> > select CPU_SUPPORTS_64BIT_KERNEL
> > select 64BIT
> > +   select HAVE_FUNCTION_TRACER
> > +   select HAVE_FUNCTION_GRAPH_TRACER
> >  
> >  endchoice
> >  
> > diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
> > index 18158be62a2b..680301bfbc4b 100644
> > --- a/arch/riscv/include/asm/Kbuild
> > +++ b/arch/riscv/include/asm/Kbuild
> > @@ -12,7 +12,6 @@ generic-y += errno.h
> >  generic-y += exec.h
> >  generic-y += fb.h
> >  generic-y += fcntl.h
> > -generic-y += ftrace.h
> >  generic-y += futex.h
> >  generic-y += hardirq.h
> >  generic-y += hash.h
> > diff --git a/arch/riscv/include/asm/ftrace.h 
> > b/arch/riscv/include/asm/ftrace.h
> > new file mode 100644
> > index ..38beadb07ad5
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/ftrace.h
> > @@ -0,0 +1,23 @@
> > +/*
> > + * Copyright (C) 2017 Andes Technology Corporation
> > + *
> > + * 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.
> > + *
> > + * 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 .
> > + */
> > +
> > +/*
> > + * The graph frame test is not possible if CONFIG_FRAME_POINTER is not 
> > enabled.
> > + * Check arch/riscv/kernel/mcount.S for detail.
> > + */
> > +#if defined(CONFIG_FUNCTION_GRAPH_TRACER) && defined(CONFIG_FRAME_POINTER)
> > +#define HAVE_FUNCTION_GRAPH_FP_TEST
> > +#endif
> > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > index 

[PATCH] mtd: nand: squash struct nand_buffers into struct nand_chip

2017-12-03 Thread Masahiro Yamada
struct nand_buffers is malloc'ed in nand_scan_tail() just for
containing three pointers.  Move the pointers into nand_chip
and delete struct nand_buffers.

Signed-off-by: Masahiro Yamada 
---

Another possibility is to keep struct nand_buffers,
but embed it in struct nand_chip.

struct nand_chip {
 ...

 struct nand_buffers buffers;

 ...
};

I will follow Boris's opinion, anyway.


 drivers/mtd/nand/brcmnand/brcmnand.c   |  2 +-
 drivers/mtd/nand/cafe_nand.c   | 15 ++
 drivers/mtd/nand/denali.c  |  2 +-
 drivers/mtd/nand/fsmc_nand.c   |  4 +-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |  4 +-
 drivers/mtd/nand/nand_base.c   | 91 +++---
 drivers/mtd/nand/nand_bbt.c|  2 +-
 drivers/mtd/nand/omap2.c   | 10 ++--
 drivers/mtd/nand/sunxi_nand.c  |  6 +--
 include/linux/mtd/rawnand.h| 23 +++--
 10 files changed, 64 insertions(+), 95 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index e0eb51d..6c9f7ec 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1681,7 +1681,7 @@ static int brcmstb_nand_verify_erased_page(struct 
mtd_info *mtd,
int ret;
 
if (!buf) {
-   buf = chip->buffers->databuf;
+   buf = chip->databuf;
/* Invalidate page cache */
chip->pagebuf = -1;
}
diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index bc558c4..1e54196 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -613,7 +613,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
uint32_t ctrl;
int err = 0;
int old_dma;
-   struct nand_buffers *nbuf;
 
/* Very old versions shared the same PCI ident for all three
   functions on the chip. Verify the class too... */
@@ -732,14 +731,12 @@ static int cafe_nand_probe(struct pci_dev *pdev,
goto out_irq;
 
cafe->dmabuf = dma_alloc_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
+   2112 + mtd->writesize + mtd->oobsize,
>dmaaddr, GFP_KERNEL);
if (!cafe->dmabuf) {
err = -ENOMEM;
goto out_irq;
}
-   cafe->nand.buffers = nbuf = (void *)cafe->dmabuf + 2112;
 
/* Set up DMA address */
cafe_writel(cafe, cafe->dmaaddr & 0x, NAND_DMA_ADDR0);
@@ -753,9 +750,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
cafe_readl(cafe, NAND_DMA_ADDR0), cafe->dmabuf);
 
/* this driver does not need the @ecccalc and @ecccode */
-   nbuf->ecccalc = NULL;
-   nbuf->ecccode = NULL;
-   nbuf->databuf = (uint8_t *)(nbuf + 1);
+   cafe->nand.databuf = (void *)cafe->dmabuf + 2112;
 
/* Restore the DMA flag */
usedma = old_dma;
@@ -802,8 +797,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
 
  out_free_dma:
dma_free_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
+   2112 + mtd->writesize + mtd->oobsize,
cafe->dmabuf, cafe->dmaaddr);
  out_irq:
/* Disable NAND IRQ in global IRQ mask register */
@@ -830,8 +824,7 @@ static void cafe_nand_remove(struct pci_dev *pdev)
free_rs(cafe->rs);
pci_iounmap(pdev, cafe->mmio);
dma_free_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
+   2112 + mtd->writesize + mtd->oobsize,
cafe->dmabuf, cafe->dmaaddr);
kfree(cafe);
 }
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 2fc964b..e1f8c6f 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -328,7 +328,7 @@ static int denali_check_erased_page(struct mtd_info *mtd,
unsigned long uncor_ecc_flags,
unsigned int max_bitflips)
 {
-   uint8_t *ecc_code = chip->buffers->ecccode;
+   uint8_t *ecc_code = chip->ecccode;
int ecc_steps = chip->ecc.steps;
int ecc_size = chip->ecc.size;
int ecc_bytes = chip->ecc.bytes;
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index eac15d9..147ca3d 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -684,8 +684,8 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, 
struct nand_chip *chip,
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
-   uint8_t *ecc_calc = 

[PATCH] mtd: nand: squash struct nand_buffers into struct nand_chip

2017-12-03 Thread Masahiro Yamada
struct nand_buffers is malloc'ed in nand_scan_tail() just for
containing three pointers.  Move the pointers into nand_chip
and delete struct nand_buffers.

Signed-off-by: Masahiro Yamada 
---

Another possibility is to keep struct nand_buffers,
but embed it in struct nand_chip.

struct nand_chip {
 ...

 struct nand_buffers buffers;

 ...
};

I will follow Boris's opinion, anyway.


 drivers/mtd/nand/brcmnand/brcmnand.c   |  2 +-
 drivers/mtd/nand/cafe_nand.c   | 15 ++
 drivers/mtd/nand/denali.c  |  2 +-
 drivers/mtd/nand/fsmc_nand.c   |  4 +-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |  4 +-
 drivers/mtd/nand/nand_base.c   | 91 +++---
 drivers/mtd/nand/nand_bbt.c|  2 +-
 drivers/mtd/nand/omap2.c   | 10 ++--
 drivers/mtd/nand/sunxi_nand.c  |  6 +--
 include/linux/mtd/rawnand.h| 23 +++--
 10 files changed, 64 insertions(+), 95 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index e0eb51d..6c9f7ec 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1681,7 +1681,7 @@ static int brcmstb_nand_verify_erased_page(struct 
mtd_info *mtd,
int ret;
 
if (!buf) {
-   buf = chip->buffers->databuf;
+   buf = chip->databuf;
/* Invalidate page cache */
chip->pagebuf = -1;
}
diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index bc558c4..1e54196 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -613,7 +613,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
uint32_t ctrl;
int err = 0;
int old_dma;
-   struct nand_buffers *nbuf;
 
/* Very old versions shared the same PCI ident for all three
   functions on the chip. Verify the class too... */
@@ -732,14 +731,12 @@ static int cafe_nand_probe(struct pci_dev *pdev,
goto out_irq;
 
cafe->dmabuf = dma_alloc_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
+   2112 + mtd->writesize + mtd->oobsize,
>dmaaddr, GFP_KERNEL);
if (!cafe->dmabuf) {
err = -ENOMEM;
goto out_irq;
}
-   cafe->nand.buffers = nbuf = (void *)cafe->dmabuf + 2112;
 
/* Set up DMA address */
cafe_writel(cafe, cafe->dmaaddr & 0x, NAND_DMA_ADDR0);
@@ -753,9 +750,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
cafe_readl(cafe, NAND_DMA_ADDR0), cafe->dmabuf);
 
/* this driver does not need the @ecccalc and @ecccode */
-   nbuf->ecccalc = NULL;
-   nbuf->ecccode = NULL;
-   nbuf->databuf = (uint8_t *)(nbuf + 1);
+   cafe->nand.databuf = (void *)cafe->dmabuf + 2112;
 
/* Restore the DMA flag */
usedma = old_dma;
@@ -802,8 +797,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
 
  out_free_dma:
dma_free_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
+   2112 + mtd->writesize + mtd->oobsize,
cafe->dmabuf, cafe->dmaaddr);
  out_irq:
/* Disable NAND IRQ in global IRQ mask register */
@@ -830,8 +824,7 @@ static void cafe_nand_remove(struct pci_dev *pdev)
free_rs(cafe->rs);
pci_iounmap(pdev, cafe->mmio);
dma_free_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
+   2112 + mtd->writesize + mtd->oobsize,
cafe->dmabuf, cafe->dmaaddr);
kfree(cafe);
 }
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 2fc964b..e1f8c6f 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -328,7 +328,7 @@ static int denali_check_erased_page(struct mtd_info *mtd,
unsigned long uncor_ecc_flags,
unsigned int max_bitflips)
 {
-   uint8_t *ecc_code = chip->buffers->ecccode;
+   uint8_t *ecc_code = chip->ecccode;
int ecc_steps = chip->ecc.steps;
int ecc_size = chip->ecc.size;
int ecc_bytes = chip->ecc.bytes;
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index eac15d9..147ca3d 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -684,8 +684,8 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, 
struct nand_chip *chip,
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
-   uint8_t *ecc_calc = chip->buffers->ecccalc;
-   uint8_t 

Re: [PATCH v2 0/8] perf tools: perf tools: Clarify overwrite and backward, bugfix

2017-12-03 Thread Namhyung Kim
On Sun, Dec 03, 2017 at 02:00:36AM +, Wang Nan wrote:
> THe final result of this patchset is removing the concept of
> 'forward/backward', merge them into the concept of 'overwrite'.
> 
> Patch 1 to 5 clear arguments lists of many functions, remove the
> 'overwrite'. Because all callers of these functions doesn't need
> the overwrite be set, we can simply remove them from arguments
> lists and adjust code as if a 'false' is given.
> 
> Patch 6 fix a bug that forget to setting readonly for overwrite
> ring buffers.
> 
> Patch 7 is suggested by Liang Kan, prevent dumpping duplicated
> data if there's no so many events between two dumpping commands.
> 
> Patch 8 is 's/backward/overwrite'. After patch 8, the concept of
> 'backward' is removed from most of the code, make it uniform with
> user interface ('--overwrite').
> 
> Cc: Kan Liang 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Cc: Zhang Mengting 

I only have a nitpick on the patch 6, but otherwise

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> 
> Wang Nan (8):
>   perf tools: Remove 'overwrite' parameter from perf_evlist__mmap
>   perf tools: Remove 'overwrite' parameter from perf_evlist__mmap_ex
>   perf tools: Remove evlist->overwrite
>   perf tools: Remove overwrite from arguments list of perf_mmap__push
>   perf tools: Remove overwrite and check_messup from mmap read
>   perf mmap: Fix perf backward recording
>   perf tool: Don't discard prev in backward mode
>   perf tools: Replace 'backward' to 'overwrite' in evlist, mmap and
> record
> 
>  tools/perf/arch/x86/tests/perf-time-to-tsc.c |  2 +-
>  tools/perf/builtin-kvm.c |  2 +-
>  tools/perf/builtin-record.c  | 16 +++---
>  tools/perf/builtin-top.c |  2 +-
>  tools/perf/builtin-trace.c   |  2 +-
>  tools/perf/tests/backward-ring-buffer.c  |  6 +--
>  tools/perf/tests/bpf.c   |  2 +-
>  tools/perf/tests/code-reading.c  |  2 +-
>  tools/perf/tests/keep-tracking.c |  2 +-
>  tools/perf/tests/mmap-basic.c|  2 +-
>  tools/perf/tests/openat-syscall-tp-fields.c  |  2 +-
>  tools/perf/tests/perf-record.c   |  2 +-
>  tools/perf/tests/sw-clock.c  |  2 +-
>  tools/perf/tests/switch-tracking.c   |  2 +-
>  tools/perf/tests/task-exit.c |  2 +-
>  tools/perf/util/evlist.c | 53 ++--
>  tools/perf/util/evlist.h |  8 ++-
>  tools/perf/util/mmap.c   | 73 
> ++--
>  tools/perf/util/mmap.h   |  4 +-
>  tools/perf/util/python.c |  2 +-
>  20 files changed, 81 insertions(+), 107 deletions(-)
> 
> -- 
> 2.10.1
> 


Re: [PATCH v2 0/8] perf tools: perf tools: Clarify overwrite and backward, bugfix

2017-12-03 Thread Namhyung Kim
On Sun, Dec 03, 2017 at 02:00:36AM +, Wang Nan wrote:
> THe final result of this patchset is removing the concept of
> 'forward/backward', merge them into the concept of 'overwrite'.
> 
> Patch 1 to 5 clear arguments lists of many functions, remove the
> 'overwrite'. Because all callers of these functions doesn't need
> the overwrite be set, we can simply remove them from arguments
> lists and adjust code as if a 'false' is given.
> 
> Patch 6 fix a bug that forget to setting readonly for overwrite
> ring buffers.
> 
> Patch 7 is suggested by Liang Kan, prevent dumpping duplicated
> data if there's no so many events between two dumpping commands.
> 
> Patch 8 is 's/backward/overwrite'. After patch 8, the concept of
> 'backward' is removed from most of the code, make it uniform with
> user interface ('--overwrite').
> 
> Cc: Kan Liang 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Cc: Zhang Mengting 

I only have a nitpick on the patch 6, but otherwise

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> 
> Wang Nan (8):
>   perf tools: Remove 'overwrite' parameter from perf_evlist__mmap
>   perf tools: Remove 'overwrite' parameter from perf_evlist__mmap_ex
>   perf tools: Remove evlist->overwrite
>   perf tools: Remove overwrite from arguments list of perf_mmap__push
>   perf tools: Remove overwrite and check_messup from mmap read
>   perf mmap: Fix perf backward recording
>   perf tool: Don't discard prev in backward mode
>   perf tools: Replace 'backward' to 'overwrite' in evlist, mmap and
> record
> 
>  tools/perf/arch/x86/tests/perf-time-to-tsc.c |  2 +-
>  tools/perf/builtin-kvm.c |  2 +-
>  tools/perf/builtin-record.c  | 16 +++---
>  tools/perf/builtin-top.c |  2 +-
>  tools/perf/builtin-trace.c   |  2 +-
>  tools/perf/tests/backward-ring-buffer.c  |  6 +--
>  tools/perf/tests/bpf.c   |  2 +-
>  tools/perf/tests/code-reading.c  |  2 +-
>  tools/perf/tests/keep-tracking.c |  2 +-
>  tools/perf/tests/mmap-basic.c|  2 +-
>  tools/perf/tests/openat-syscall-tp-fields.c  |  2 +-
>  tools/perf/tests/perf-record.c   |  2 +-
>  tools/perf/tests/sw-clock.c  |  2 +-
>  tools/perf/tests/switch-tracking.c   |  2 +-
>  tools/perf/tests/task-exit.c |  2 +-
>  tools/perf/util/evlist.c | 53 ++--
>  tools/perf/util/evlist.h |  8 ++-
>  tools/perf/util/mmap.c   | 73 
> ++--
>  tools/perf/util/mmap.h   |  4 +-
>  tools/perf/util/python.c |  2 +-
>  20 files changed, 81 insertions(+), 107 deletions(-)
> 
> -- 
> 2.10.1
> 


[PATCH v2] ARM64: dts: meson-axg: enable IR controller

2017-12-03 Thread Yixun Lan
Enable IR remote controller which find in Amlogic's Meson-AXG SoC.

Signed-off-by: Yixun Lan 

---

Changes since v1 at [1]:
 - drop the compatbile 'amlogic,meson-gx-ir'

[1]
 http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005527.html
---
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts |  6 ++
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 14 ++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts 
b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 0864d1ff2d9b..ca676cafdbb3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -34,3 +34,9 @@
pinctrl-0 = <_z_pins>;
pinctrl-names = "default";
 };
+
+ {
+   status = "okay";
+   pinctrl-0 = <_input_ao_pins>;
+   pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 9bb85893c1b7..f68f709762dd 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -616,6 +616,13 @@
#gpio-cells = <2>;
gpio-ranges = <_aobus 0 0 15>;
};
+
+   remote_input_ao_pins: remote_input_ao {
+   mux {
+   groups = "remote_input_ao";
+   function = "remote_input_ao";
+   };
+   };
};
 
i2c_AO: i2c@5000 {
@@ -664,6 +671,13 @@
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
+
+   ir: ir@8000 {
+   compatible = "amlogic,meson-gxbb-ir";
+   reg = <0x0 0x8000 0x0 0x20>;
+   interrupts = ;
+   status = "disabled";
+   };
};
};
 };
-- 
2.15.0



[PATCH v2] ARM64: dts: meson-axg: enable IR controller

2017-12-03 Thread Yixun Lan
Enable IR remote controller which find in Amlogic's Meson-AXG SoC.

Signed-off-by: Yixun Lan 

---

Changes since v1 at [1]:
 - drop the compatbile 'amlogic,meson-gx-ir'

[1]
 http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005527.html
---
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts |  6 ++
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 14 ++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts 
b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 0864d1ff2d9b..ca676cafdbb3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -34,3 +34,9 @@
pinctrl-0 = <_z_pins>;
pinctrl-names = "default";
 };
+
+ {
+   status = "okay";
+   pinctrl-0 = <_input_ao_pins>;
+   pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 9bb85893c1b7..f68f709762dd 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -616,6 +616,13 @@
#gpio-cells = <2>;
gpio-ranges = <_aobus 0 0 15>;
};
+
+   remote_input_ao_pins: remote_input_ao {
+   mux {
+   groups = "remote_input_ao";
+   function = "remote_input_ao";
+   };
+   };
};
 
i2c_AO: i2c@5000 {
@@ -664,6 +671,13 @@
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
+
+   ir: ir@8000 {
+   compatible = "amlogic,meson-gxbb-ir";
+   reg = <0x0 0x8000 0x0 0x20>;
+   interrupts = ;
+   status = "disabled";
+   };
};
};
 };
-- 
2.15.0



Re: [PATCH v2 6/8] perf mmap: Fix perf backward recording

2017-12-03 Thread Namhyung Kim
Hi,

On Sun, Dec 03, 2017 at 02:00:42AM +, Wang Nan wrote:
> perf record backward recording doesn't work as we expected: it never
> overwrite when ring buffer full.
> 
> Test:
> 
> (Run a busy printing task background like this:
> 
>  while True:
>  print 123
> 
> send SIGUSR2 to perf to capture snapshot.)
> 
>  # ./perf record --overwrite -e raw_syscalls:sys_enter -e 
> raw_syscalls:sys_exit --exclude-perf -a --switch-output
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101520743 ]
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101521251 ]
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101521692 ]
>  ^C[ perf record: Woken up 1 times to write data ]
>  [ perf record: Dump perf.data.2017110101521936 ]
>  [ perf record: Captured and wrote 0.826 MB perf.data. ]
> 
>  # ./perf script -i ./perf.data.2017110101520743 | head -n3
>  perf  2717 [000] 12449.310785: raw_syscalls:sys_enter: NR 16 (5, 
> 2400, 0, 59, 100, 0)
>  perf  2717 [000] 12449.310790: raw_syscalls:sys_enter: NR 7 
> (4112340, 2, , 3df, 100, 0)
>python  2545 [000] 12449.310800:  raw_syscalls:sys_exit: NR 1 = 4
>  # ./perf script -i ./perf.data.2017110101521251 | head -n3
>  perf  2717 [000] 12449.310785: raw_syscalls:sys_enter: NR 16 (5, 
> 2400, 0, 59, 100, 0)
>  perf  2717 [000] 12449.310790: raw_syscalls:sys_enter: NR 7 
> (4112340, 2, , 3df, 100, 0)
>python  2545 [000] 12449.310800:  raw_syscalls:sys_exit: NR 1 = 4
>  # ./perf script -i ./perf.data.2017110101521692 | head -n3
>  perf  2717 [000] 12449.310785: raw_syscalls:sys_enter: NR 16 (5, 
> 2400, 0, 59, 100, 0)
>  perf  2717 [000] 12449.310790: raw_syscalls:sys_enter: NR 7 
> (4112340, 2, , 3df, 100, 0)
>python  2545 [000] 12449.310800:  raw_syscalls:sys_exit: NR 1 = 4
> 
> Timestamps are never change, but my background task is a dead loop, can
> easily overwhelme the ring buffer.
> 
> This patch fix it by force unsetting PROT_WRITE for backward ring
> buffer, so all backward ring buffer become overwrite ring buffer.
> 
> Test result:
> 
>  # ./perf record --overwrite -e raw_syscalls:sys_enter -e 
> raw_syscalls:sys_exit --exclude-perf -a --switch-output
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101285323 ]
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101290053 ]
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101290446 ]
>  ^C[ perf record: Woken up 1 times to write data ]
>  [ perf record: Dump perf.data.2017110101290837 ]
>  [ perf record: Captured and wrote 0.826 MB perf.data. ]
>  # ./perf script -i ./perf.data.2017110101285323 | head -n3
>python  2545 [000] 11064.268083:  raw_syscalls:sys_exit: NR 1 = 4
>python  2545 [000] 11064.268084: raw_syscalls:sys_enter: NR 1 (1, 
> 12cc330, 4, 7fc237280370, 7fc2373d0700, 2c7b0)
>python  2545 [000] 11064.268086:  raw_syscalls:sys_exit: NR 1 = 4
>  # ./perf script -i ./perf.data.2017110101290 | head -n3
>  failed to open ./perf.data.2017110101290: No such file or directory
>  # ./perf script -i ./perf.data.2017110101290053 | head -n3
>python  2545 [000] 11071.564062: raw_syscalls:sys_enter: NR 1 (1, 
> 12cc330, 4, 7fc237280370, 7fc2373d0700, 2c7b0)
>python  2545 [000] 11071.564064:  raw_syscalls:sys_exit: NR 1 = 4
>python  2545 [000] 11071.564066: raw_syscalls:sys_enter: NR 1 (1, 
> 12cc330, 4, 7fc237280370, 7fc2373d0700, 2c7b0)
>  # ./perf script -i ./perf.data.2017110101290 | head -n3
>  perf.data.2017110101290053  perf.data.2017110101290446  
> perf.data.2017110101290837
>  # ./perf script -i ./perf.data.2017110101290446 | head -n3
>  sshd  1321 [000] 11075.499473:  raw_syscalls:sys_exit: NR 14 = 0
>  sshd  1321 [000] 11075.499474: raw_syscalls:sys_enter: NR 14 (2, 
> 7ffe98899490, 0, 8, 0, 3000)
>  sshd  1321 [000] 11075.499474:  raw_syscalls:sys_exit: NR 14 = 0
>  # ./perf script -i ./perf.data.2017110101290837 | head -n3
>python  2545 [000] 11079.280844:  raw_syscalls:sys_exit: NR 1 = 4
>python  2545 [000] 11079.280847: raw_syscalls:sys_enter: NR 1 (1, 
> 12cc330, 4, 7fc237280370, 7fc2373d0700, 2c7b0)
>python  2545 [000] 11079.280850:  raw_syscalls:sys_exit: NR 1 = 4
> 
> Signed-off-by: Wang Nan 
> ---
>  tools/perf/util/evlist.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 68c1f95..bb70aef 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -799,7 +799,7 @@ perf_evlist__should_poll(struct perf_evlist *evlist 
> __maybe_unused,
>  }
>  
>  static int 

Re: [PATCH v2 6/8] perf mmap: Fix perf backward recording

2017-12-03 Thread Namhyung Kim
Hi,

On Sun, Dec 03, 2017 at 02:00:42AM +, Wang Nan wrote:
> perf record backward recording doesn't work as we expected: it never
> overwrite when ring buffer full.
> 
> Test:
> 
> (Run a busy printing task background like this:
> 
>  while True:
>  print 123
> 
> send SIGUSR2 to perf to capture snapshot.)
> 
>  # ./perf record --overwrite -e raw_syscalls:sys_enter -e 
> raw_syscalls:sys_exit --exclude-perf -a --switch-output
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101520743 ]
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101521251 ]
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101521692 ]
>  ^C[ perf record: Woken up 1 times to write data ]
>  [ perf record: Dump perf.data.2017110101521936 ]
>  [ perf record: Captured and wrote 0.826 MB perf.data. ]
> 
>  # ./perf script -i ./perf.data.2017110101520743 | head -n3
>  perf  2717 [000] 12449.310785: raw_syscalls:sys_enter: NR 16 (5, 
> 2400, 0, 59, 100, 0)
>  perf  2717 [000] 12449.310790: raw_syscalls:sys_enter: NR 7 
> (4112340, 2, , 3df, 100, 0)
>python  2545 [000] 12449.310800:  raw_syscalls:sys_exit: NR 1 = 4
>  # ./perf script -i ./perf.data.2017110101521251 | head -n3
>  perf  2717 [000] 12449.310785: raw_syscalls:sys_enter: NR 16 (5, 
> 2400, 0, 59, 100, 0)
>  perf  2717 [000] 12449.310790: raw_syscalls:sys_enter: NR 7 
> (4112340, 2, , 3df, 100, 0)
>python  2545 [000] 12449.310800:  raw_syscalls:sys_exit: NR 1 = 4
>  # ./perf script -i ./perf.data.2017110101521692 | head -n3
>  perf  2717 [000] 12449.310785: raw_syscalls:sys_enter: NR 16 (5, 
> 2400, 0, 59, 100, 0)
>  perf  2717 [000] 12449.310790: raw_syscalls:sys_enter: NR 7 
> (4112340, 2, , 3df, 100, 0)
>python  2545 [000] 12449.310800:  raw_syscalls:sys_exit: NR 1 = 4
> 
> Timestamps are never change, but my background task is a dead loop, can
> easily overwhelme the ring buffer.
> 
> This patch fix it by force unsetting PROT_WRITE for backward ring
> buffer, so all backward ring buffer become overwrite ring buffer.
> 
> Test result:
> 
>  # ./perf record --overwrite -e raw_syscalls:sys_enter -e 
> raw_syscalls:sys_exit --exclude-perf -a --switch-output
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101285323 ]
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101290053 ]
>  [ perf record: dump data: Woken up 1 times ]
>  [ perf record: Dump perf.data.2017110101290446 ]
>  ^C[ perf record: Woken up 1 times to write data ]
>  [ perf record: Dump perf.data.2017110101290837 ]
>  [ perf record: Captured and wrote 0.826 MB perf.data. ]
>  # ./perf script -i ./perf.data.2017110101285323 | head -n3
>python  2545 [000] 11064.268083:  raw_syscalls:sys_exit: NR 1 = 4
>python  2545 [000] 11064.268084: raw_syscalls:sys_enter: NR 1 (1, 
> 12cc330, 4, 7fc237280370, 7fc2373d0700, 2c7b0)
>python  2545 [000] 11064.268086:  raw_syscalls:sys_exit: NR 1 = 4
>  # ./perf script -i ./perf.data.2017110101290 | head -n3
>  failed to open ./perf.data.2017110101290: No such file or directory
>  # ./perf script -i ./perf.data.2017110101290053 | head -n3
>python  2545 [000] 11071.564062: raw_syscalls:sys_enter: NR 1 (1, 
> 12cc330, 4, 7fc237280370, 7fc2373d0700, 2c7b0)
>python  2545 [000] 11071.564064:  raw_syscalls:sys_exit: NR 1 = 4
>python  2545 [000] 11071.564066: raw_syscalls:sys_enter: NR 1 (1, 
> 12cc330, 4, 7fc237280370, 7fc2373d0700, 2c7b0)
>  # ./perf script -i ./perf.data.2017110101290 | head -n3
>  perf.data.2017110101290053  perf.data.2017110101290446  
> perf.data.2017110101290837
>  # ./perf script -i ./perf.data.2017110101290446 | head -n3
>  sshd  1321 [000] 11075.499473:  raw_syscalls:sys_exit: NR 14 = 0
>  sshd  1321 [000] 11075.499474: raw_syscalls:sys_enter: NR 14 (2, 
> 7ffe98899490, 0, 8, 0, 3000)
>  sshd  1321 [000] 11075.499474:  raw_syscalls:sys_exit: NR 14 = 0
>  # ./perf script -i ./perf.data.2017110101290837 | head -n3
>python  2545 [000] 11079.280844:  raw_syscalls:sys_exit: NR 1 = 4
>python  2545 [000] 11079.280847: raw_syscalls:sys_enter: NR 1 (1, 
> 12cc330, 4, 7fc237280370, 7fc2373d0700, 2c7b0)
>python  2545 [000] 11079.280850:  raw_syscalls:sys_exit: NR 1 = 4
> 
> Signed-off-by: Wang Nan 
> ---
>  tools/perf/util/evlist.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 68c1f95..bb70aef 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -799,7 +799,7 @@ perf_evlist__should_poll(struct perf_evlist *evlist 
> __maybe_unused,
>  }
>  
>  static int perf_evlist__mmap_per_evsel(struct 

Re: [PATCH v18 10/10] virtio-balloon: don't report free pages when page poisoning is enabled

2017-12-03 Thread Wei Wang

On 12/01/2017 11:49 PM, Michael S. Tsirkin wrote:

On Wed, Nov 29, 2017 at 09:55:26PM +0800, Wei Wang wrote:

The guest free pages should not be discarded by the live migration thread
when page poisoning is enabled with PAGE_POISONING_NO_SANITY=n, because
skipping the transfer of such poisoned free pages will trigger false
positive when new pages are allocated and checked on the destination.
This patch skips the reporting of free pages in the above case.

Reported-by: Michael S. Tsirkin 
Signed-off-by: Wei Wang 
Cc: Michal Hocko 
---
  drivers/virtio/virtio_balloon.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 035bd3a..6ac4cff 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -652,7 +652,9 @@ static void report_free_page(struct work_struct *work)
/* Start by sending the obtained cmd id to the host with an outbuf */
send_one_desc(vb, vb->free_page_vq, virt_to_phys(>start_cmd_id),
  sizeof(uint32_t), false, true, false);
-   walk_free_mem_block(vb, 0, _balloon_send_free_pages);
+   if (!(page_poisoning_enabled() &&
+   !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY)))
+   walk_free_mem_block(vb, 0, _balloon_send_free_pages);
/*
 * End by sending the stop id to the host with an outbuf. Use the
 * non-batching mode here to trigger a kick after adding the stop id.

PAGE_POISONING_ZERO is actually OK.


I think the 0-filled pages still need to be sent. If the host on the 
destination doesn't use PAGE_POISONING_ZERO, then the pages it offers to 
the guest on the destination may have non-0 values.






But I really would prefer it that we still send pages to host,
otherwise debugging becomes much harder.

And it does not have to be completely useless, even though
you can not discard them as they would be zero-filled then.

How about a config field telling host what should be there in the free
pages? This way even though host can not discard them, host can send
them out without reading them, still a win.




OK, but I think we would need two 32-bit config registers:

__u32 page_poison_val; // stores the PAGE_POISON VALUE, but it couldn't 
indicate if page poisoning is in use


__u32 special_features; // set bit 0 to indicate page poisoning is in use

#define VIRTIO_BALLOON_SF_PAGE_POISON (1 << 0)


Best,
Wei






Re: [PATCH v18 10/10] virtio-balloon: don't report free pages when page poisoning is enabled

2017-12-03 Thread Wei Wang

On 12/01/2017 11:49 PM, Michael S. Tsirkin wrote:

On Wed, Nov 29, 2017 at 09:55:26PM +0800, Wei Wang wrote:

The guest free pages should not be discarded by the live migration thread
when page poisoning is enabled with PAGE_POISONING_NO_SANITY=n, because
skipping the transfer of such poisoned free pages will trigger false
positive when new pages are allocated and checked on the destination.
This patch skips the reporting of free pages in the above case.

Reported-by: Michael S. Tsirkin 
Signed-off-by: Wei Wang 
Cc: Michal Hocko 
---
  drivers/virtio/virtio_balloon.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 035bd3a..6ac4cff 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -652,7 +652,9 @@ static void report_free_page(struct work_struct *work)
/* Start by sending the obtained cmd id to the host with an outbuf */
send_one_desc(vb, vb->free_page_vq, virt_to_phys(>start_cmd_id),
  sizeof(uint32_t), false, true, false);
-   walk_free_mem_block(vb, 0, _balloon_send_free_pages);
+   if (!(page_poisoning_enabled() &&
+   !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY)))
+   walk_free_mem_block(vb, 0, _balloon_send_free_pages);
/*
 * End by sending the stop id to the host with an outbuf. Use the
 * non-batching mode here to trigger a kick after adding the stop id.

PAGE_POISONING_ZERO is actually OK.


I think the 0-filled pages still need to be sent. If the host on the 
destination doesn't use PAGE_POISONING_ZERO, then the pages it offers to 
the guest on the destination may have non-0 values.






But I really would prefer it that we still send pages to host,
otherwise debugging becomes much harder.

And it does not have to be completely useless, even though
you can not discard them as they would be zero-filled then.

How about a config field telling host what should be there in the free
pages? This way even though host can not discard them, host can send
them out without reading them, still a win.




OK, but I think we would need two 32-bit config registers:

__u32 page_poison_val; // stores the PAGE_POISON VALUE, but it couldn't 
indicate if page poisoning is in use


__u32 special_features; // set bit 0 to indicate page poisoning is in use

#define VIRTIO_BALLOON_SF_PAGE_POISON (1 << 0)


Best,
Wei






[PATCH] clk: meson: make the spinlock naming more specific

2017-12-03 Thread Yixun Lan
Make the spinlock more specific, so better for lockdep
debugging and ctags/grep.

Signed-off-by: Yixun Lan 

---

this patch try to address the issue which bring up by Stephen at [1]
[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005534.html
---
 drivers/clk/meson/axg.c |  34 +++---
 drivers/clk/meson/clkc.h|   2 +-
 drivers/clk/meson/gxbb.c| 112 ++--
 drivers/clk/meson/meson8b.c |  24 +-
 4 files changed, 86 insertions(+), 86 deletions(-)

diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
index 03f57541bc1e..349cbcd299d8 100644
--- a/drivers/clk/meson/axg.c
+++ b/drivers/clk/meson/axg.c
@@ -19,7 +19,7 @@
 #include "clkc.h"
 #include "axg.h"
 
-static DEFINE_SPINLOCK(clk_lock);
+static DEFINE_SPINLOCK(meson_clk_lock);
 
 static const struct pll_rate_table sys_pll_rate_table[] = {
PLL_RATE(2400, 56, 1, 2),
@@ -129,7 +129,7 @@ static struct meson_clk_pll axg_fixed_pll = {
.shift   = 16,
.width   = 2,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "fixed_pll",
.ops = _clk_pll_ro_ops,
@@ -157,7 +157,7 @@ static struct meson_clk_pll axg_sys_pll = {
},
.rate_table = sys_pll_rate_table,
.rate_count = ARRAY_SIZE(sys_pll_rate_table),
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "sys_pll",
.ops = _clk_pll_ro_ops,
@@ -291,7 +291,7 @@ static struct meson_clk_pll axg_gp0_pll = {
},
.rate_table = axg_gp0_pll_rate_table,
.rate_count = ARRAY_SIZE(axg_gp0_pll_rate_table),
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "gp0_pll",
.ops = _clk_pll_ops,
@@ -383,7 +383,7 @@ static struct meson_clk_mpll axg_mpll0 = {
.shift   = 25,
.width   = 1,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpll0",
.ops = _clk_mpll_ops,
@@ -413,7 +413,7 @@ static struct meson_clk_mpll axg_mpll1 = {
.shift   = 14,
.width   = 1,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpll1",
.ops = _clk_mpll_ops,
@@ -443,7 +443,7 @@ static struct meson_clk_mpll axg_mpll2 = {
.shift   = 14,
.width   = 1,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpll2",
.ops = _clk_mpll_ops,
@@ -473,7 +473,7 @@ static struct meson_clk_mpll axg_mpll3 = {
.shift   = 0,
.width   = 1,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpll3",
.ops = _clk_mpll_ops,
@@ -499,7 +499,7 @@ static struct clk_mux axg_mpeg_clk_sel = {
.shift = 12,
.flags = CLK_MUX_READ_ONLY,
.table = mux_table_clk81,
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpeg_clk_sel",
.ops = _mux_ro_ops,
@@ -518,7 +518,7 @@ static struct clk_divider axg_mpeg_clk_div = {
.reg = (void *)HHI_MPEG_CLK_CNTL,
.shift = 0,
.width = 7,
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpeg_clk_div",
.ops = _divider_ops,
@@ -531,7 +531,7 @@ static struct clk_divider axg_mpeg_clk_div = {
 static struct clk_gate axg_clk81 = {
.reg = (void *)HHI_MPEG_CLK_CNTL,
.bit_idx = 7,
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "clk81",
.ops = _gate_ops,
@@ -557,7 +557,7 @@ static struct clk_mux axg_sd_emmc_b_clk0_sel = {
.reg = (void *)HHI_SD_EMMC_CLK_CNTL,
.mask = 0x7,
.shift = 25,
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data) {
.name = "sd_emmc_b_clk0_sel",
.ops = _mux_ops,
@@ -571,7 +571,7 @@ static struct clk_divider axg_sd_emmc_b_clk0_div = {
.reg = (void *)HHI_SD_EMMC_CLK_CNTL,
.shift = 16,
.width = 7,
-   .lock = _lock,
+   .lock = _clk_lock,
.flags = CLK_DIVIDER_ROUND_CLOSEST,
.hw.init = &(struct clk_init_data) {
.name = "sd_emmc_b_clk0_div",
@@ -585,7 +585,7 @@ static struct clk_divider axg_sd_emmc_b_clk0_div = {
 static struct clk_gate axg_sd_emmc_b_clk0 = {
.reg = (void *)HHI_SD_EMMC_CLK_CNTL,
.bit_idx = 23,
-   .lock 

[PATCH] Revert "powerpc: Do not call ppc_md.panic in fadump panic notifier"

2017-12-03 Thread David Gibson
This reverts commit a3b2cb30f252b21a6f962e0dd107c8b897ca65e4.

The earlier patch tried to fix problems with panic on powerpc in
certain circumstances, where some output from the generic panic code
was being dropped.

Unfortunately, it breaks things worse in other circumstances.  In
particular when running a PAPR guest, it will now attempt to reboot
instead of informing the hypervisor (KVM or PowerVM) that the guest
has crashed.  The crash notification is important to some
virtualization management layers.

Since the circumstances in which the original patch helped are
somewhat obscure, revert it for now until we figure out how to do it
properly.

Signed-off-by: David Gibson 
---
 arch/powerpc/include/asm/machdep.h |  1 +
 arch/powerpc/include/asm/setup.h   |  1 +
 arch/powerpc/kernel/fadump.c   | 22 --
 arch/powerpc/kernel/setup-common.c | 27 +++
 arch/powerpc/platforms/ps3/setup.c | 15 +++
 arch/powerpc/platforms/pseries/setup.c |  1 +
 6 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 73b92017b6d7..cd2fc1cc1cc7 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -76,6 +76,7 @@ struct machdep_calls {
 
void __noreturn (*restart)(char *cmd);
void __noreturn (*halt)(void);
+   void(*panic)(char *str);
void(*cpu_die)(void);
 
long(*time_init)(void); /* Optional, may be NULL */
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 257d23dbf55d..cf00ec26303a 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -24,6 +24,7 @@ extern void reloc_got2(unsigned long);
 
 void check_for_initrd(void);
 void initmem_init(void);
+void setup_panic(void);
 #define ARCH_PANIC_TIMEOUT 180
 
 #ifdef CONFIG_PPC_PSERIES
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 04ea5c04fd24..3c2c2688918f 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1462,25 +1462,6 @@ static void fadump_init_files(void)
return;
 }
 
-static int fadump_panic_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
-   /*
-* If firmware-assisted dump has been registered then trigger
-* firmware-assisted dump and let firmware handle everything
-* else. If this returns, then fadump was not registered, so
-* go through the rest of the panic path.
-*/
-   crash_fadump(NULL, ptr);
-
-   return NOTIFY_DONE;
-}
-
-static struct notifier_block fadump_panic_block = {
-   .notifier_call = fadump_panic_event,
-   .priority = INT_MIN /* may not return; must be done last */
-};
-
 /*
  * Prepare for firmware-assisted dump.
  */
@@ -1513,9 +1494,6 @@ int __init setup_fadump(void)
init_fadump_mem_struct(, fw_dump.reserve_dump_area_start);
fadump_init_files();
 
-   atomic_notifier_chain_register(_notifier_list,
-   _panic_block);
-
return 1;
 }
 subsys_initcall(setup_fadump);
diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 2075322cd225..9d213542a48b 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -704,6 +704,30 @@ int check_legacy_ioport(unsigned long base_port)
 }
 EXPORT_SYMBOL(check_legacy_ioport);
 
+static int ppc_panic_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+   /*
+* If firmware-assisted dump has been registered then trigger
+* firmware-assisted dump and let firmware handle everything else.
+*/
+   crash_fadump(NULL, ptr);
+   ppc_md.panic(ptr);  /* May not return */
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_panic_block = {
+   .notifier_call = ppc_panic_event,
+   .priority = INT_MIN /* may not return; must be done last */
+};
+
+void __init setup_panic(void)
+{
+   if (!ppc_md.panic)
+   return;
+   atomic_notifier_chain_register(_notifier_list, _panic_block);
+}
+
 #ifdef CONFIG_CHECK_CACHE_COHERENCY
 /*
  * For platforms that have configurable cache-coherency.  This function
@@ -848,6 +872,9 @@ void __init setup_arch(char **cmdline_p)
/* Probe the machine type, establish ppc_md. */
probe_machine();
 
+   /* Setup panic notifier if requested by the platform. */
+   setup_panic();
+
/*
 * Configure ppc_md.power_save (ppc32 only, 64-bit machines do
 * it from their respective probe() function.
diff --git a/arch/powerpc/platforms/ps3/setup.c 
b/arch/powerpc/platforms/ps3/setup.c
index 9dabea6e1443..6244bc849469 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ 

[PATCH] clk: meson: make the spinlock naming more specific

2017-12-03 Thread Yixun Lan
Make the spinlock more specific, so better for lockdep
debugging and ctags/grep.

Signed-off-by: Yixun Lan 

---

this patch try to address the issue which bring up by Stephen at [1]
[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005534.html
---
 drivers/clk/meson/axg.c |  34 +++---
 drivers/clk/meson/clkc.h|   2 +-
 drivers/clk/meson/gxbb.c| 112 ++--
 drivers/clk/meson/meson8b.c |  24 +-
 4 files changed, 86 insertions(+), 86 deletions(-)

diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
index 03f57541bc1e..349cbcd299d8 100644
--- a/drivers/clk/meson/axg.c
+++ b/drivers/clk/meson/axg.c
@@ -19,7 +19,7 @@
 #include "clkc.h"
 #include "axg.h"
 
-static DEFINE_SPINLOCK(clk_lock);
+static DEFINE_SPINLOCK(meson_clk_lock);
 
 static const struct pll_rate_table sys_pll_rate_table[] = {
PLL_RATE(2400, 56, 1, 2),
@@ -129,7 +129,7 @@ static struct meson_clk_pll axg_fixed_pll = {
.shift   = 16,
.width   = 2,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "fixed_pll",
.ops = _clk_pll_ro_ops,
@@ -157,7 +157,7 @@ static struct meson_clk_pll axg_sys_pll = {
},
.rate_table = sys_pll_rate_table,
.rate_count = ARRAY_SIZE(sys_pll_rate_table),
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "sys_pll",
.ops = _clk_pll_ro_ops,
@@ -291,7 +291,7 @@ static struct meson_clk_pll axg_gp0_pll = {
},
.rate_table = axg_gp0_pll_rate_table,
.rate_count = ARRAY_SIZE(axg_gp0_pll_rate_table),
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "gp0_pll",
.ops = _clk_pll_ops,
@@ -383,7 +383,7 @@ static struct meson_clk_mpll axg_mpll0 = {
.shift   = 25,
.width   = 1,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpll0",
.ops = _clk_mpll_ops,
@@ -413,7 +413,7 @@ static struct meson_clk_mpll axg_mpll1 = {
.shift   = 14,
.width   = 1,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpll1",
.ops = _clk_mpll_ops,
@@ -443,7 +443,7 @@ static struct meson_clk_mpll axg_mpll2 = {
.shift   = 14,
.width   = 1,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpll2",
.ops = _clk_mpll_ops,
@@ -473,7 +473,7 @@ static struct meson_clk_mpll axg_mpll3 = {
.shift   = 0,
.width   = 1,
},
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpll3",
.ops = _clk_mpll_ops,
@@ -499,7 +499,7 @@ static struct clk_mux axg_mpeg_clk_sel = {
.shift = 12,
.flags = CLK_MUX_READ_ONLY,
.table = mux_table_clk81,
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpeg_clk_sel",
.ops = _mux_ro_ops,
@@ -518,7 +518,7 @@ static struct clk_divider axg_mpeg_clk_div = {
.reg = (void *)HHI_MPEG_CLK_CNTL,
.shift = 0,
.width = 7,
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "mpeg_clk_div",
.ops = _divider_ops,
@@ -531,7 +531,7 @@ static struct clk_divider axg_mpeg_clk_div = {
 static struct clk_gate axg_clk81 = {
.reg = (void *)HHI_MPEG_CLK_CNTL,
.bit_idx = 7,
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data){
.name = "clk81",
.ops = _gate_ops,
@@ -557,7 +557,7 @@ static struct clk_mux axg_sd_emmc_b_clk0_sel = {
.reg = (void *)HHI_SD_EMMC_CLK_CNTL,
.mask = 0x7,
.shift = 25,
-   .lock = _lock,
+   .lock = _clk_lock,
.hw.init = &(struct clk_init_data) {
.name = "sd_emmc_b_clk0_sel",
.ops = _mux_ops,
@@ -571,7 +571,7 @@ static struct clk_divider axg_sd_emmc_b_clk0_div = {
.reg = (void *)HHI_SD_EMMC_CLK_CNTL,
.shift = 16,
.width = 7,
-   .lock = _lock,
+   .lock = _clk_lock,
.flags = CLK_DIVIDER_ROUND_CLOSEST,
.hw.init = &(struct clk_init_data) {
.name = "sd_emmc_b_clk0_div",
@@ -585,7 +585,7 @@ static struct clk_divider axg_sd_emmc_b_clk0_div = {
 static struct clk_gate axg_sd_emmc_b_clk0 = {
.reg = (void *)HHI_SD_EMMC_CLK_CNTL,
.bit_idx = 23,
-   .lock = _lock,
+   .lock 

[PATCH] Revert "powerpc: Do not call ppc_md.panic in fadump panic notifier"

2017-12-03 Thread David Gibson
This reverts commit a3b2cb30f252b21a6f962e0dd107c8b897ca65e4.

The earlier patch tried to fix problems with panic on powerpc in
certain circumstances, where some output from the generic panic code
was being dropped.

Unfortunately, it breaks things worse in other circumstances.  In
particular when running a PAPR guest, it will now attempt to reboot
instead of informing the hypervisor (KVM or PowerVM) that the guest
has crashed.  The crash notification is important to some
virtualization management layers.

Since the circumstances in which the original patch helped are
somewhat obscure, revert it for now until we figure out how to do it
properly.

Signed-off-by: David Gibson 
---
 arch/powerpc/include/asm/machdep.h |  1 +
 arch/powerpc/include/asm/setup.h   |  1 +
 arch/powerpc/kernel/fadump.c   | 22 --
 arch/powerpc/kernel/setup-common.c | 27 +++
 arch/powerpc/platforms/ps3/setup.c | 15 +++
 arch/powerpc/platforms/pseries/setup.c |  1 +
 6 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 73b92017b6d7..cd2fc1cc1cc7 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -76,6 +76,7 @@ struct machdep_calls {
 
void __noreturn (*restart)(char *cmd);
void __noreturn (*halt)(void);
+   void(*panic)(char *str);
void(*cpu_die)(void);
 
long(*time_init)(void); /* Optional, may be NULL */
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 257d23dbf55d..cf00ec26303a 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -24,6 +24,7 @@ extern void reloc_got2(unsigned long);
 
 void check_for_initrd(void);
 void initmem_init(void);
+void setup_panic(void);
 #define ARCH_PANIC_TIMEOUT 180
 
 #ifdef CONFIG_PPC_PSERIES
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 04ea5c04fd24..3c2c2688918f 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1462,25 +1462,6 @@ static void fadump_init_files(void)
return;
 }
 
-static int fadump_panic_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
-   /*
-* If firmware-assisted dump has been registered then trigger
-* firmware-assisted dump and let firmware handle everything
-* else. If this returns, then fadump was not registered, so
-* go through the rest of the panic path.
-*/
-   crash_fadump(NULL, ptr);
-
-   return NOTIFY_DONE;
-}
-
-static struct notifier_block fadump_panic_block = {
-   .notifier_call = fadump_panic_event,
-   .priority = INT_MIN /* may not return; must be done last */
-};
-
 /*
  * Prepare for firmware-assisted dump.
  */
@@ -1513,9 +1494,6 @@ int __init setup_fadump(void)
init_fadump_mem_struct(, fw_dump.reserve_dump_area_start);
fadump_init_files();
 
-   atomic_notifier_chain_register(_notifier_list,
-   _panic_block);
-
return 1;
 }
 subsys_initcall(setup_fadump);
diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 2075322cd225..9d213542a48b 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -704,6 +704,30 @@ int check_legacy_ioport(unsigned long base_port)
 }
 EXPORT_SYMBOL(check_legacy_ioport);
 
+static int ppc_panic_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+   /*
+* If firmware-assisted dump has been registered then trigger
+* firmware-assisted dump and let firmware handle everything else.
+*/
+   crash_fadump(NULL, ptr);
+   ppc_md.panic(ptr);  /* May not return */
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_panic_block = {
+   .notifier_call = ppc_panic_event,
+   .priority = INT_MIN /* may not return; must be done last */
+};
+
+void __init setup_panic(void)
+{
+   if (!ppc_md.panic)
+   return;
+   atomic_notifier_chain_register(_notifier_list, _panic_block);
+}
+
 #ifdef CONFIG_CHECK_CACHE_COHERENCY
 /*
  * For platforms that have configurable cache-coherency.  This function
@@ -848,6 +872,9 @@ void __init setup_arch(char **cmdline_p)
/* Probe the machine type, establish ppc_md. */
probe_machine();
 
+   /* Setup panic notifier if requested by the platform. */
+   setup_panic();
+
/*
 * Configure ppc_md.power_save (ppc32 only, 64-bit machines do
 * it from their respective probe() function.
diff --git a/arch/powerpc/platforms/ps3/setup.c 
b/arch/powerpc/platforms/ps3/setup.c
index 9dabea6e1443..6244bc849469 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ 

[PATCH 1/2] clk: sunxi-ng: Support fixed post-dividers on MP style clocks

2017-12-03 Thread Chen-Yu Tsai
On the A64, the MMC module clocks are fixed in the new timing mode,
i.e. they do not have a bit to select the mode. These clocks have
a 2x divider somewhere between the clock and the MMC module.

To be consistent with other SoCs supporting the new timing mode,
we model the 2x divider as a fixed post-divider on the MMC module
clocks.

To do this, we first add fixed post-divider to the MP style clocks,
which the MMC module clocks are.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu_mp.c | 20 ++--
 drivers/clk/sunxi-ng/ccu_mp.h | 24 
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index 688855e7dc8c..5d0af4051737 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -50,12 +50,19 @@ static unsigned long ccu_mp_round_rate(struct 
ccu_mux_internal *mux,
unsigned int max_m, max_p;
unsigned int m, p;
 
+   if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate *= cmp->fixed_post_div;
+
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
 
ccu_mp_find_best(*parent_rate, rate, max_m, max_p, , );
+   rate = *parent_rate / p / m;
+
+   if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate /= cmp->fixed_post_div;
 
-   return *parent_rate / p / m;
+   return rate;
 }
 
 static void ccu_mp_disable(struct clk_hw *hw)
@@ -83,6 +90,7 @@ static unsigned long ccu_mp_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
 {
struct ccu_mp *cmp = hw_to_ccu_mp(hw);
+   unsigned long rate;
unsigned int m, p;
u32 reg;
 
@@ -101,7 +109,11 @@ static unsigned long ccu_mp_recalc_rate(struct clk_hw *hw,
p = reg >> cmp->p.shift;
p &= (1 << cmp->p.width) - 1;
 
-   return (parent_rate >> p) / m;
+   rate = (parent_rate >> p) / m;
+   if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate /= cmp->fixed_post_div;
+
+   return rate;
 }
 
 static int ccu_mp_determine_rate(struct clk_hw *hw,
@@ -129,6 +141,10 @@ static int ccu_mp_set_rate(struct clk_hw *hw, unsigned 
long rate,
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
 
+   /* Adjust target rate according to post-dividers */
+   if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate = rate * cmp->fixed_post_div;
+
ccu_mp_find_best(parent_rate, rate, max_m, max_p, , );
 
spin_lock_irqsave(cmp->common.lock, flags);
diff --git a/drivers/clk/sunxi-ng/ccu_mp.h b/drivers/clk/sunxi-ng/ccu_mp.h
index aaef11d747ea..5107635e61de 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.h
+++ b/drivers/clk/sunxi-ng/ccu_mp.h
@@ -33,9 +33,33 @@ struct ccu_mp {
struct ccu_div_internal m;
struct ccu_div_internal p;
struct ccu_mux_internal mux;
+
+   unsigned intfixed_post_div;
+
struct ccu_common   common;
 };
 
+#define SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(_struct, _name, _parents, _reg, \
+  _mshift, _mwidth,\
+  _pshift, _pwidth,\
+  _muxshift, _muxwidth,\
+  _gate, _postdiv, _flags) \
+   struct ccu_mp _struct = {   \
+   .enable = _gate,\
+   .m  = _SUNXI_CCU_DIV(_mshift, _mwidth), \
+   .p  = _SUNXI_CCU_DIV(_pshift, _pwidth), \
+   .mux= _SUNXI_CCU_MUX(_muxshift, _muxwidth), \
+   .fixed_post_div = _postdiv, \
+   .common = { \
+   .reg= _reg, \
+   .features   = CCU_FEATURE_FIXED_POSTDIV,\
+   .hw.init= CLK_HW_INIT_PARENTS(_name,\
+ _parents, \
+ _mp_ops, \
+ _flags),  \
+   }   \
+   }
+
 #define SUNXI_CCU_MP_WITH_MUX_GATE(_struct, _name, _parents, _reg, \
   _mshift, _mwidth,\
   _pshift, _pwidth,\
-- 
2.15.0



[PATCH 0/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

2017-12-03 Thread Chen-Yu Tsai
Hi,

This is a small fix to get MMC performance up to proper speeds on the
A64. According to the BSP kernel, the MMC module clocks have a /2 fixed
post-divider between the clock output and the MMC module, like what
we've seen with the "new MMC timing mode" on the A83T, but the A64 does
not have the mode switch.

Sub-par performance was observed on the Banana Pi M64 eMMC. It only
reached half the read throughput of other Banana Pi boards, using a
standard sequential readout with a large block size. After these
patches, the performance is up to spec.

The A64 can also do DDR transfer modes, but the clock delay config
registers in the MMC module are different from what we've seen so
far. One can just force enable DDR modes without tuning the delays,
and it does work. Proper support for this is left for another time.


ChenYu

Chen-Yu Tsai (2):
  clk: sunxi-ng: Support fixed post-dividers on MP style clocks
  clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module
clocks

 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 +++
 drivers/clk/sunxi-ng/ccu_mp.c | 20 ++--
 drivers/clk/sunxi-ng/ccu_mp.h | 24 +++
 3 files changed, 79 insertions(+), 22 deletions(-)

-- 
2.15.0



[PATCH 1/2] clk: sunxi-ng: Support fixed post-dividers on MP style clocks

2017-12-03 Thread Chen-Yu Tsai
On the A64, the MMC module clocks are fixed in the new timing mode,
i.e. they do not have a bit to select the mode. These clocks have
a 2x divider somewhere between the clock and the MMC module.

To be consistent with other SoCs supporting the new timing mode,
we model the 2x divider as a fixed post-divider on the MMC module
clocks.

To do this, we first add fixed post-divider to the MP style clocks,
which the MMC module clocks are.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu_mp.c | 20 ++--
 drivers/clk/sunxi-ng/ccu_mp.h | 24 
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index 688855e7dc8c..5d0af4051737 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -50,12 +50,19 @@ static unsigned long ccu_mp_round_rate(struct 
ccu_mux_internal *mux,
unsigned int max_m, max_p;
unsigned int m, p;
 
+   if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate *= cmp->fixed_post_div;
+
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
 
ccu_mp_find_best(*parent_rate, rate, max_m, max_p, , );
+   rate = *parent_rate / p / m;
+
+   if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate /= cmp->fixed_post_div;
 
-   return *parent_rate / p / m;
+   return rate;
 }
 
 static void ccu_mp_disable(struct clk_hw *hw)
@@ -83,6 +90,7 @@ static unsigned long ccu_mp_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
 {
struct ccu_mp *cmp = hw_to_ccu_mp(hw);
+   unsigned long rate;
unsigned int m, p;
u32 reg;
 
@@ -101,7 +109,11 @@ static unsigned long ccu_mp_recalc_rate(struct clk_hw *hw,
p = reg >> cmp->p.shift;
p &= (1 << cmp->p.width) - 1;
 
-   return (parent_rate >> p) / m;
+   rate = (parent_rate >> p) / m;
+   if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate /= cmp->fixed_post_div;
+
+   return rate;
 }
 
 static int ccu_mp_determine_rate(struct clk_hw *hw,
@@ -129,6 +141,10 @@ static int ccu_mp_set_rate(struct clk_hw *hw, unsigned 
long rate,
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
 
+   /* Adjust target rate according to post-dividers */
+   if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate = rate * cmp->fixed_post_div;
+
ccu_mp_find_best(parent_rate, rate, max_m, max_p, , );
 
spin_lock_irqsave(cmp->common.lock, flags);
diff --git a/drivers/clk/sunxi-ng/ccu_mp.h b/drivers/clk/sunxi-ng/ccu_mp.h
index aaef11d747ea..5107635e61de 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.h
+++ b/drivers/clk/sunxi-ng/ccu_mp.h
@@ -33,9 +33,33 @@ struct ccu_mp {
struct ccu_div_internal m;
struct ccu_div_internal p;
struct ccu_mux_internal mux;
+
+   unsigned intfixed_post_div;
+
struct ccu_common   common;
 };
 
+#define SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(_struct, _name, _parents, _reg, \
+  _mshift, _mwidth,\
+  _pshift, _pwidth,\
+  _muxshift, _muxwidth,\
+  _gate, _postdiv, _flags) \
+   struct ccu_mp _struct = {   \
+   .enable = _gate,\
+   .m  = _SUNXI_CCU_DIV(_mshift, _mwidth), \
+   .p  = _SUNXI_CCU_DIV(_pshift, _pwidth), \
+   .mux= _SUNXI_CCU_MUX(_muxshift, _muxwidth), \
+   .fixed_post_div = _postdiv, \
+   .common = { \
+   .reg= _reg, \
+   .features   = CCU_FEATURE_FIXED_POSTDIV,\
+   .hw.init= CLK_HW_INIT_PARENTS(_name,\
+ _parents, \
+ _mp_ops, \
+ _flags),  \
+   }   \
+   }
+
 #define SUNXI_CCU_MP_WITH_MUX_GATE(_struct, _name, _parents, _reg, \
   _mshift, _mwidth,\
   _pshift, _pwidth,\
-- 
2.15.0



[PATCH 0/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

2017-12-03 Thread Chen-Yu Tsai
Hi,

This is a small fix to get MMC performance up to proper speeds on the
A64. According to the BSP kernel, the MMC module clocks have a /2 fixed
post-divider between the clock output and the MMC module, like what
we've seen with the "new MMC timing mode" on the A83T, but the A64 does
not have the mode switch.

Sub-par performance was observed on the Banana Pi M64 eMMC. It only
reached half the read throughput of other Banana Pi boards, using a
standard sequential readout with a large block size. After these
patches, the performance is up to spec.

The A64 can also do DDR transfer modes, but the clock delay config
registers in the MMC module are different from what we've seen so
far. One can just force enable DDR modes without tuning the delays,
and it does work. Proper support for this is left for another time.


ChenYu

Chen-Yu Tsai (2):
  clk: sunxi-ng: Support fixed post-dividers on MP style clocks
  clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module
clocks

 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 +++
 drivers/clk/sunxi-ng/ccu_mp.c | 20 ++--
 drivers/clk/sunxi-ng/ccu_mp.h | 24 +++
 3 files changed, 79 insertions(+), 22 deletions(-)

-- 
2.15.0



[PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

2017-12-03 Thread Chen-Yu Tsai
On the A64, the MMC module clocks are fixed in the new timing mode,
i.e. they do not have a bit to select the mode. These clocks have
a 2x divider somewhere between the clock and the MMC module.

To be consistent with other SoCs supporting the new timing mode,
we model the 2x divider as a fixed post-divider on the MMC module
clocks.

This patch adds the post-dividers to the MMC clocks.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 +++
 1 file changed, 37 insertions(+), 20 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 2bb4cabf802f..ee9c12cf3f08 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -400,28 +400,45 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", 
mod0_default_parents, 0x080,
  BIT(31),  /* gate */
  0);
 
+/*
+ * MMC clocks are the new timing mode (see A83T & H3) variety, but without
+ * the mode switch. This means they have a 2x post divider between the clock
+ * and the MMC module. This is not documented in the manual, but is taken
+ * into consideration when setting the mmc module clocks in the BSP kernel.
+ * Without it, MMC performance is degraded.
+ *
+ * We model it here to be consistent with other SoCs supporting this mode.
+ * The alternative would be to add the 2x multiplier when setting the MMC
+ * module clock in the MMC driver, just for the A64.
+ */
 static const char * const mmc_default_parents[] = { "osc24M", "pll-periph0-2x",
"pll-periph1-2x" };
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", mmc_default_parents, 0x088,
- 0, 4, /* M */
- 16, 2,/* P */
- 24, 2,/* mux */
- BIT(31),  /* gate */
- 0);
-
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", mmc_default_parents, 0x08c,
- 0, 4, /* M */
- 16, 2,/* P */
- 24, 2,/* mux */
- BIT(31),  /* gate */
- 0);
-
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mmc_default_parents, 0x090,
- 0, 4, /* M */
- 16, 2,/* P */
- 24, 2,/* mux */
- BIT(31),  /* gate */
- 0);
+static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc0_clk, "mmc0",
+ mmc_default_parents, 0x088,
+ 0, 4, /* M */
+ 16, 2,/* P */
+ 24, 2,/* mux */
+ BIT(31),  /* gate */
+ 2,/* post-div */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc1_clk, "mmc1",
+ mmc_default_parents, 0x08c,
+ 0, 4, /* M */
+ 16, 2,/* P */
+ 24, 2,/* mux */
+ BIT(31),  /* gate */
+ 2,/* post-div */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc2_clk, "mmc2",
+ mmc_default_parents, 0x090,
+ 0, 4, /* M */
+ 16, 2,/* P */
+ 24, 2,/* mux */
+ BIT(31),  /* gate */
+ 2,/* post-div */
+ 0);
 
 static const char * const ts_parents[] = { "osc24M", "pll-periph0", };
 static SUNXI_CCU_MP_WITH_MUX_GATE(ts_clk, "ts", ts_parents, 0x098,
-- 
2.15.0



[PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

2017-12-03 Thread Chen-Yu Tsai
On the A64, the MMC module clocks are fixed in the new timing mode,
i.e. they do not have a bit to select the mode. These clocks have
a 2x divider somewhere between the clock and the MMC module.

To be consistent with other SoCs supporting the new timing mode,
we model the 2x divider as a fixed post-divider on the MMC module
clocks.

This patch adds the post-dividers to the MMC clocks.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 +++
 1 file changed, 37 insertions(+), 20 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 2bb4cabf802f..ee9c12cf3f08 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -400,28 +400,45 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", 
mod0_default_parents, 0x080,
  BIT(31),  /* gate */
  0);
 
+/*
+ * MMC clocks are the new timing mode (see A83T & H3) variety, but without
+ * the mode switch. This means they have a 2x post divider between the clock
+ * and the MMC module. This is not documented in the manual, but is taken
+ * into consideration when setting the mmc module clocks in the BSP kernel.
+ * Without it, MMC performance is degraded.
+ *
+ * We model it here to be consistent with other SoCs supporting this mode.
+ * The alternative would be to add the 2x multiplier when setting the MMC
+ * module clock in the MMC driver, just for the A64.
+ */
 static const char * const mmc_default_parents[] = { "osc24M", "pll-periph0-2x",
"pll-periph1-2x" };
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", mmc_default_parents, 0x088,
- 0, 4, /* M */
- 16, 2,/* P */
- 24, 2,/* mux */
- BIT(31),  /* gate */
- 0);
-
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", mmc_default_parents, 0x08c,
- 0, 4, /* M */
- 16, 2,/* P */
- 24, 2,/* mux */
- BIT(31),  /* gate */
- 0);
-
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mmc_default_parents, 0x090,
- 0, 4, /* M */
- 16, 2,/* P */
- 24, 2,/* mux */
- BIT(31),  /* gate */
- 0);
+static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc0_clk, "mmc0",
+ mmc_default_parents, 0x088,
+ 0, 4, /* M */
+ 16, 2,/* P */
+ 24, 2,/* mux */
+ BIT(31),  /* gate */
+ 2,/* post-div */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc1_clk, "mmc1",
+ mmc_default_parents, 0x08c,
+ 0, 4, /* M */
+ 16, 2,/* P */
+ 24, 2,/* mux */
+ BIT(31),  /* gate */
+ 2,/* post-div */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc2_clk, "mmc2",
+ mmc_default_parents, 0x090,
+ 0, 4, /* M */
+ 16, 2,/* P */
+ 24, 2,/* mux */
+ BIT(31),  /* gate */
+ 2,/* post-div */
+ 0);
 
 static const char * const ts_parents[] = { "osc24M", "pll-periph0", };
 static SUNXI_CCU_MP_WITH_MUX_GATE(ts_clk, "ts", ts_parents, 0x098,
-- 
2.15.0



Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

2017-12-03 Thread Kaiwan N Billimoria
> On Mon, Dec 4, 2017 at 10:25 AM, Tobin C. Harding  wrote:
>>
>> > With the 'eval', no warning, it's fine.
>>
>> Why not use hex()?
>
>> >
>> > foreach my $config_file (@config_files) {
>> > +   $config_file =~ s/\R*//g;
>>
>> Is there some reason you don't use chomp()?
>

Wrt your suggestions:

---
diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
index 9906dcf8b807..260b52e456f1 100755
--- a/scripts/leaking_addresses.pl
+++ b/scripts/leaking_addresses.pl
@@ -266,7 +266,7 @@ sub is_false_positive
 sub is_false_positive_ix86_32
 {
my ($match) = @_;
-   state $page_offset = eval get_page_offset(); # only gets called once
+   state $page_offset = hex get_page_offset(); # only gets called once

if ($match =~ '\b(0x)?(f|F){8}\b') {
return 1;
@@ -313,7 +313,7 @@ sub get_page_offset
}

foreach my $config_file (@config_files) {
-   $config_file =~ s/\R*//g;
+   chomp $config_file;
$page_offset = parse_kernel_config_file($config_file);
if ($page_offset ne "") {
return $page_offset;


Thanks & Regards,
Kaiwan.


Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

2017-12-03 Thread Kaiwan N Billimoria
> On Mon, Dec 4, 2017 at 10:25 AM, Tobin C. Harding  wrote:
>>
>> > With the 'eval', no warning, it's fine.
>>
>> Why not use hex()?
>
>> >
>> > foreach my $config_file (@config_files) {
>> > +   $config_file =~ s/\R*//g;
>>
>> Is there some reason you don't use chomp()?
>

Wrt your suggestions:

---
diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
index 9906dcf8b807..260b52e456f1 100755
--- a/scripts/leaking_addresses.pl
+++ b/scripts/leaking_addresses.pl
@@ -266,7 +266,7 @@ sub is_false_positive
 sub is_false_positive_ix86_32
 {
my ($match) = @_;
-   state $page_offset = eval get_page_offset(); # only gets called once
+   state $page_offset = hex get_page_offset(); # only gets called once

if ($match =~ '\b(0x)?(f|F){8}\b') {
return 1;
@@ -313,7 +313,7 @@ sub get_page_offset
}

foreach my $config_file (@config_files) {
-   $config_file =~ s/\R*//g;
+   chomp $config_file;
$page_offset = parse_kernel_config_file($config_file);
if ($page_offset ne "") {
return $page_offset;


Thanks & Regards,
Kaiwan.


Re: [Bridge] [PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

2017-12-03 Thread Linus Lüssing
On Mon, Dec 04, 2017 at 05:53:35AM +0100, Linus Lüssing wrote:
> And so, no I do not have this patch. I looked at it now, but it
> does not seem to have any relation with .matchinfo, does it?

Relation between .usersize and .checkentry I ment, not
.usersize and .matchinfo.


Re: [Bridge] [PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

2017-12-03 Thread Linus Lüssing
On Mon, Dec 04, 2017 at 05:53:35AM +0100, Linus Lüssing wrote:
> And so, no I do not have this patch. I looked at it now, but it
> does not seem to have any relation with .matchinfo, does it?

Relation between .usersize and .checkentry I ment, not
.usersize and .matchinfo.


[PATCH v2 1/4] lockdep: Apply crossrelease to PG_locked locks

2017-12-03 Thread Byungchul Park
Although lock_page() and its family can cause deadlock, lockdep have not
worked with them, becasue unlock_page() might be called in a different
context from the acquire context, which violated lockdep's assumption.

Now CONFIG_LOCKDEP_CROSSRELEASE has been introduced, lockdep can work
with page locks.

Signed-off-by: Byungchul Park 
---
 include/linux/mm_types.h |   8 
 include/linux/pagemap.h  | 101 ---
 lib/Kconfig.debug|   7 
 mm/filemap.c |   4 +-
 mm/page_alloc.c  |   3 ++
 5 files changed, 115 insertions(+), 8 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index c85f11d..263b861 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -17,6 +17,10 @@
 
 #include 
 
+#ifdef CONFIG_LOCKDEP_PAGELOCK
+#include 
+#endif
+
 #ifndef AT_VECTOR_SIZE_ARCH
 #define AT_VECTOR_SIZE_ARCH 0
 #endif
@@ -218,6 +222,10 @@ struct page {
 #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
int _last_cpupid;
 #endif
+
+#ifdef CONFIG_LOCKDEP_PAGELOCK
+   struct lockdep_map_cross map;
+#endif
 }
 /*
  * The struct page can be forced to be double word aligned so that atomic ops
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index e08b533..35b4f67 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -15,6 +15,9 @@
 #include 
 #include  /* for in_interrupt() */
 #include 
+#ifdef CONFIG_LOCKDEP_PAGELOCK
+#include 
+#endif
 
 /*
  * Bits in mapping->flags.
@@ -457,26 +460,91 @@ static inline pgoff_t linear_page_index(struct 
vm_area_struct *vma,
return pgoff;
 }
 
+#ifdef CONFIG_LOCKDEP_PAGELOCK
+#define lock_page_init(p)  \
+do {   \
+   static struct lock_class_key __key; \
+   lockdep_init_map_crosslock((struct lockdep_map *)&(p)->map, \
+   "(PG_locked)" #p, &__key, 0);   \
+} while (0)
+
+static inline void lock_page_acquire(struct page *page, int try)
+{
+   page = compound_head(page);
+   lock_acquire_exclusive((struct lockdep_map *)>map, 0,
+  try, NULL, _RET_IP_);
+}
+
+static inline void lock_page_release(struct page *page)
+{
+   page = compound_head(page);
+   /*
+* lock_commit_crosslock() is necessary for crosslocks.
+*/
+   lock_commit_crosslock((struct lockdep_map *)>map);
+   lock_release((struct lockdep_map *)>map, 0, _RET_IP_);
+}
+#else
+static inline void lock_page_init(struct page *page) {}
+static inline void lock_page_free(struct page *page) {}
+static inline void lock_page_acquire(struct page *page, int try) {}
+static inline void lock_page_release(struct page *page) {}
+#endif
+
 extern void __lock_page(struct page *page);
 extern int __lock_page_killable(struct page *page);
 extern int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
unsigned int flags);
-extern void unlock_page(struct page *page);
+extern void do_raw_unlock_page(struct page *page);
 
-static inline int trylock_page(struct page *page)
+static inline void unlock_page(struct page *page)
+{
+   lock_page_release(page);
+   do_raw_unlock_page(page);
+}
+
+static inline int do_raw_trylock_page(struct page *page)
 {
page = compound_head(page);
return (likely(!test_and_set_bit_lock(PG_locked, >flags)));
 }
 
+static inline int trylock_page(struct page *page)
+{
+   if (do_raw_trylock_page(page)) {
+   lock_page_acquire(page, 1);
+   return 1;
+   }
+   return 0;
+}
+
 /*
  * lock_page may only be called if we have the page's inode pinned.
  */
 static inline void lock_page(struct page *page)
 {
might_sleep();
-   if (!trylock_page(page))
+
+   if (!do_raw_trylock_page(page))
__lock_page(page);
+   /*
+* acquire() must be after actual lock operation for crosslocks.
+* This way a crosslock and current lock can be ordered like:
+*
+*  CONTEXT 1   CONTEXT 2
+*  -   -
+*  lock A (cross)
+*  acquire A
+*X = atomic_inc_return(_gen_id)
+*  ~
+*  acquire B
+*Y = atomic_read_acquire(_gen_id)
+*  lock B
+*
+* so that 'lock A and then lock B' can be seen globally,
+* if X <= Y.
+*/
+   lock_page_acquire(page, 0);
 }
 
 /*
@@ -486,9 +554,20 @@ static inline void lock_page(struct page *page)
  */
 static inline int lock_page_killable(struct page *page)
 {
+   int ret;
+
might_sleep();
-   if (!trylock_page(page))
-   return 

[PATCH v2 1/4] lockdep: Apply crossrelease to PG_locked locks

2017-12-03 Thread Byungchul Park
Although lock_page() and its family can cause deadlock, lockdep have not
worked with them, becasue unlock_page() might be called in a different
context from the acquire context, which violated lockdep's assumption.

Now CONFIG_LOCKDEP_CROSSRELEASE has been introduced, lockdep can work
with page locks.

Signed-off-by: Byungchul Park 
---
 include/linux/mm_types.h |   8 
 include/linux/pagemap.h  | 101 ---
 lib/Kconfig.debug|   7 
 mm/filemap.c |   4 +-
 mm/page_alloc.c  |   3 ++
 5 files changed, 115 insertions(+), 8 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index c85f11d..263b861 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -17,6 +17,10 @@
 
 #include 
 
+#ifdef CONFIG_LOCKDEP_PAGELOCK
+#include 
+#endif
+
 #ifndef AT_VECTOR_SIZE_ARCH
 #define AT_VECTOR_SIZE_ARCH 0
 #endif
@@ -218,6 +222,10 @@ struct page {
 #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
int _last_cpupid;
 #endif
+
+#ifdef CONFIG_LOCKDEP_PAGELOCK
+   struct lockdep_map_cross map;
+#endif
 }
 /*
  * The struct page can be forced to be double word aligned so that atomic ops
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index e08b533..35b4f67 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -15,6 +15,9 @@
 #include 
 #include  /* for in_interrupt() */
 #include 
+#ifdef CONFIG_LOCKDEP_PAGELOCK
+#include 
+#endif
 
 /*
  * Bits in mapping->flags.
@@ -457,26 +460,91 @@ static inline pgoff_t linear_page_index(struct 
vm_area_struct *vma,
return pgoff;
 }
 
+#ifdef CONFIG_LOCKDEP_PAGELOCK
+#define lock_page_init(p)  \
+do {   \
+   static struct lock_class_key __key; \
+   lockdep_init_map_crosslock((struct lockdep_map *)&(p)->map, \
+   "(PG_locked)" #p, &__key, 0);   \
+} while (0)
+
+static inline void lock_page_acquire(struct page *page, int try)
+{
+   page = compound_head(page);
+   lock_acquire_exclusive((struct lockdep_map *)>map, 0,
+  try, NULL, _RET_IP_);
+}
+
+static inline void lock_page_release(struct page *page)
+{
+   page = compound_head(page);
+   /*
+* lock_commit_crosslock() is necessary for crosslocks.
+*/
+   lock_commit_crosslock((struct lockdep_map *)>map);
+   lock_release((struct lockdep_map *)>map, 0, _RET_IP_);
+}
+#else
+static inline void lock_page_init(struct page *page) {}
+static inline void lock_page_free(struct page *page) {}
+static inline void lock_page_acquire(struct page *page, int try) {}
+static inline void lock_page_release(struct page *page) {}
+#endif
+
 extern void __lock_page(struct page *page);
 extern int __lock_page_killable(struct page *page);
 extern int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
unsigned int flags);
-extern void unlock_page(struct page *page);
+extern void do_raw_unlock_page(struct page *page);
 
-static inline int trylock_page(struct page *page)
+static inline void unlock_page(struct page *page)
+{
+   lock_page_release(page);
+   do_raw_unlock_page(page);
+}
+
+static inline int do_raw_trylock_page(struct page *page)
 {
page = compound_head(page);
return (likely(!test_and_set_bit_lock(PG_locked, >flags)));
 }
 
+static inline int trylock_page(struct page *page)
+{
+   if (do_raw_trylock_page(page)) {
+   lock_page_acquire(page, 1);
+   return 1;
+   }
+   return 0;
+}
+
 /*
  * lock_page may only be called if we have the page's inode pinned.
  */
 static inline void lock_page(struct page *page)
 {
might_sleep();
-   if (!trylock_page(page))
+
+   if (!do_raw_trylock_page(page))
__lock_page(page);
+   /*
+* acquire() must be after actual lock operation for crosslocks.
+* This way a crosslock and current lock can be ordered like:
+*
+*  CONTEXT 1   CONTEXT 2
+*  -   -
+*  lock A (cross)
+*  acquire A
+*X = atomic_inc_return(_gen_id)
+*  ~
+*  acquire B
+*Y = atomic_read_acquire(_gen_id)
+*  lock B
+*
+* so that 'lock A and then lock B' can be seen globally,
+* if X <= Y.
+*/
+   lock_page_acquire(page, 0);
 }
 
 /*
@@ -486,9 +554,20 @@ static inline void lock_page(struct page *page)
  */
 static inline int lock_page_killable(struct page *page)
 {
+   int ret;
+
might_sleep();
-   if (!trylock_page(page))
-   return __lock_page_killable(page);
+
+   if 

[PATCH v2 4/4] lockdep: Add a boot parameter enabling to track page locks using lockdep and disable it by default

2017-12-03 Thread Byungchul Park
To track page locks using lockdep, we need a huge memory space for
lockdep_map per page. So, it would be better to make it disabled by
default and provide a boot parameter to turn it on. Do it.

Suggested-by: Michal Hocko 
Signed-off-by: Byungchul Park 
---
 Documentation/admin-guide/kernel-parameters.txt |  7 +++
 lib/Kconfig.debug   |  5 -
 mm/filemap.c| 23 +++
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index f20ed5e..5e8d15d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -712,6 +712,13 @@
crossrelease_fullstack
[KNL] Allow to record full stack trace in cross-release
 
+   lockdep_pagelock=
+   [KNL] Boot-time lockdep_pagelock enabling option.
+   Storage of lockdep_map per page to track lock_page()/
+   unlock_page() is disabled by default. With this switch,
+   we can turn it on.
+   on: enable the feature
+
cryptomgr.notests
 [KNL] Disable crypto self-tests
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 45fdb3a..c609e97 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1185,7 +1185,10 @@ config LOCKDEP_PAGELOCK
select PAGE_EXTENSION
help
 PG_locked lock is a kind of crosslock. Using crossrelease feature,
-PG_locked lock can work with lockdep.
+PG_locked lock can work with lockdep. Even if you include this
+feature on your build, it is disabled in default. You should pass
+"lockdep_pagelock=on" to boot parameter in order to enable it. It
+consumes a fair amount of memory if enabled.
 
 config BOOTPARAM_LOCKDEP_CROSSRELEASE_FULLSTACK
bool "Enable the boot parameter, crossrelease_fullstack"
diff --git a/mm/filemap.c b/mm/filemap.c
index 34251fb..cb7b20b 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1231,8 +1231,24 @@ int __lock_page_or_retry(struct page *page, struct 
mm_struct *mm,
 
 #ifdef CONFIG_LOCKDEP_PAGELOCK
 
+static int lockdep_pagelock;
+static int __init allow_lockdep_pagelock(char *str)
+{
+   if (!str)
+   return -EINVAL;
+
+   if (!strcmp(str, "on"))
+   lockdep_pagelock = 1;
+
+   return 0;
+}
+early_param("lockdep_pagelock", allow_lockdep_pagelock);
+
 static bool need_lockdep_pagelock(void)
 {
+   if (!lockdep_pagelock)
+   return false;
+
return true;
 }
 
@@ -1286,6 +1302,10 @@ static void init_zones_in_node(pg_data_t *pgdat)
 static void init_lockdep_pagelock(void)
 {
pg_data_t *pgdat;
+
+   if (!lockdep_pagelock)
+   return;
+
for_each_online_pgdat(pgdat)
init_zones_in_node(pgdat);
 }
@@ -1305,6 +1325,9 @@ struct lockdep_map *get_page_map(struct page *p)
 {
struct page_ext *e;
 
+   if (!lockdep_pagelock)
+   return NULL;
+
e = lookup_page_ext(p);
if (!e)
return NULL;
-- 
1.9.1



[PATCH v2 4/4] lockdep: Add a boot parameter enabling to track page locks using lockdep and disable it by default

2017-12-03 Thread Byungchul Park
To track page locks using lockdep, we need a huge memory space for
lockdep_map per page. So, it would be better to make it disabled by
default and provide a boot parameter to turn it on. Do it.

Suggested-by: Michal Hocko 
Signed-off-by: Byungchul Park 
---
 Documentation/admin-guide/kernel-parameters.txt |  7 +++
 lib/Kconfig.debug   |  5 -
 mm/filemap.c| 23 +++
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index f20ed5e..5e8d15d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -712,6 +712,13 @@
crossrelease_fullstack
[KNL] Allow to record full stack trace in cross-release
 
+   lockdep_pagelock=
+   [KNL] Boot-time lockdep_pagelock enabling option.
+   Storage of lockdep_map per page to track lock_page()/
+   unlock_page() is disabled by default. With this switch,
+   we can turn it on.
+   on: enable the feature
+
cryptomgr.notests
 [KNL] Disable crypto self-tests
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 45fdb3a..c609e97 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1185,7 +1185,10 @@ config LOCKDEP_PAGELOCK
select PAGE_EXTENSION
help
 PG_locked lock is a kind of crosslock. Using crossrelease feature,
-PG_locked lock can work with lockdep.
+PG_locked lock can work with lockdep. Even if you include this
+feature on your build, it is disabled in default. You should pass
+"lockdep_pagelock=on" to boot parameter in order to enable it. It
+consumes a fair amount of memory if enabled.
 
 config BOOTPARAM_LOCKDEP_CROSSRELEASE_FULLSTACK
bool "Enable the boot parameter, crossrelease_fullstack"
diff --git a/mm/filemap.c b/mm/filemap.c
index 34251fb..cb7b20b 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1231,8 +1231,24 @@ int __lock_page_or_retry(struct page *page, struct 
mm_struct *mm,
 
 #ifdef CONFIG_LOCKDEP_PAGELOCK
 
+static int lockdep_pagelock;
+static int __init allow_lockdep_pagelock(char *str)
+{
+   if (!str)
+   return -EINVAL;
+
+   if (!strcmp(str, "on"))
+   lockdep_pagelock = 1;
+
+   return 0;
+}
+early_param("lockdep_pagelock", allow_lockdep_pagelock);
+
 static bool need_lockdep_pagelock(void)
 {
+   if (!lockdep_pagelock)
+   return false;
+
return true;
 }
 
@@ -1286,6 +1302,10 @@ static void init_zones_in_node(pg_data_t *pgdat)
 static void init_lockdep_pagelock(void)
 {
pg_data_t *pgdat;
+
+   if (!lockdep_pagelock)
+   return;
+
for_each_online_pgdat(pgdat)
init_zones_in_node(pgdat);
 }
@@ -1305,6 +1325,9 @@ struct lockdep_map *get_page_map(struct page *p)
 {
struct page_ext *e;
 
+   if (!lockdep_pagelock)
+   return NULL;
+
e = lookup_page_ext(p);
if (!e)
return NULL;
-- 
1.9.1



  1   2   3   4   5   6   7   >