Re: [PATCH 5/5] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Neil Armstrong]

On 23/01/2018 18:08, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.
> 
> v2: Convert armada, rcar, and sun4i as well
> 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Cc: Daniel Vetter 
> Cc: Gustavo Padovan 
> Cc: Sean Paul 
> Cc: Philipp Zabel 
> Cc: CK Hu 
> Cc: Neil Armstrong 
> Cc: Rob Clark 
> Cc: Ben Skeggs 
> Cc: Laurent Pinchart 
> Cc: Sandy Huang 
> Cc: "Heiko Stübner" 
> Cc: Maxime Ripard 
> Cc: Thierry Reding 
> Cc: VMware Graphics 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Shawn Guo 
> Cc: Archit Taneja 
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: Russell King 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Thierry Reding 
> Reviewed-by: Archit Taneja  #msm
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  7 +--
>  drivers/gpu/drm/arm/malidp_planes.c |  7 +--
>  drivers/gpu/drm/armada/armada_crtc.c|  8 ++--
>  drivers/gpu/drm/armada/armada_overlay.c |  8 ++--
>  drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
>  drivers/gpu/drm/drm_plane_helper.c  | 11 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  6 --
>  drivers/gpu/drm/i915/intel_display.c| 12 
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  7 +--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  7 +--
>  drivers/gpu/drm/meson/meson_plane.c |  7 +--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 14 ++
>  drivers/gpu/drm/nouveau/nv50_display.c  | 12 
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  7 +--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 +--
>  drivers/gpu/drm/sun4i/sun8i_ui_layer.c  |  7 +--
>  drivers/gpu/drm/sun4i/sun8i_vi_layer.c  |  7 +--
>  drivers/gpu/drm/tegra/plane.c   |  7 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  7 +--
>  drivers/gpu/drm/zte/zx_plane.c  | 13 +
>  include/drm/drm_atomic_helper.h |  1 -
>  include/drm/drm_plane_helper.h  |  1 -
>  22 files changed, 28 insertions(+), 147 deletions(-)
> 
[...]

> diff --git a/drivers/gpu/drm/meson/meson_plane.c 
> b/drivers/gpu/drm/meson/meson_plane.c
> index 3801bee1f9e6..c78a3a59f58c 100644
> --- a/drivers/gpu/drm/meson/meson_plane.c
> +++ b/drivers/gpu/drm/meson/meson_plane.c
> @@ -49,7 +49,6 @@ static int meson_plane_atomic_check(struct drm_plane *plane,
>   struct drm_plane_state *state)
>  {
>   struct drm_crtc_state *crtc_state;
> - struct drm_rect clip = { 0, };
>  
>   if (!state->crtc)
>   return 0;
> @@ -58,11 +57,7 @@ static int meson_plane_atomic_check(struct drm_plane 
> *plane,
>   if (IS_ERR(crtc_state))
>   return PTR_ERR(crtc_state);
>  
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(_state->mode,
> -, );
> -
> - return drm_atomic_helper_check_plane_state(state, crtc_state, ,
> + return drm_atomic_helper_check_plane_state(state, crtc_state,
>  DRM_PLANE_HELPER_NO_SCALING,
>  DRM_PLANE_HELPER_NO_SCALING,
>  true, true);

[...]

> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 4842ee9485ce..26aaba58d6ce 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -40,7 +40,6 @@ int drm_atomic_helper_check_modeset(struct drm_device *dev,
>   struct drm_atomic_state *state);
>  int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
>   const struct drm_crtc_state *crtc_state,
> - const struct drm_rect *clip,
>   

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

[Frank Rowand]

On 01/25/18 15:53, Tyrel Datwyler wrote:
> On 01/25/2018 01:49 PM, Frank Rowand wrote:
>> Hi Wolfram,
>>
>> On 01/25/18 03:03, Steven Rostedt wrote:
>>> On Wed, 24 Jan 2018 22:55:13 -0800
>>> Frank Rowand  wrote:
>>>
 Hi Steve,
>>>

 Off the top of your head, can you tell me know early in the boot
 process a trace_event can be called and successfully provide the
 data to someone trying to debug early boot issues?
>>>
>>> The trace events are enabled by early_initcall().
>>
>> < snip >
>>
>> This means that ftrace can not be used for the of_node_get(),
>> of_node_put(), and of_node_release() debug info, because
>> these functions are called before early_initcall().  Please
>> use pr_debug() for these functions.
> 
> I would argue that early boot debugging doesn't completely negate the
> usefulness of this tracing infrastructure.

I did not say or imply that it did.  I am pointing out that this
implementation does not meet the needs of other use cases.  And
potentially provides misleading information (or more precisely
misleading lack of information) in some other use cases.


> I get that no information
> is available in the trace up until ftrace is setup by its
> early_initcall, but I still found issues after early boot using this
> patch and I would hope that it would be somewhat obvious if
> references are out of whack once the ftrace data becomes available.
> In the dynamic case on Power we often do reconfig well after boot on
> live systems which produces a lot of reference put/gets. This patch
> made it easy to identify several reference leaks and underflows in
> our attach and detach logic with the added aid of being able to turn
> on the stacktrace for each call in the ftrace data.

Yes, you can get stacktraces relatively easily.  This is the strongest
argument for using ftrace.

My assumption has been that the stack trace is useful for of_node_get()
and of_node_put().  Is there _large_ value to the stack trace for
of_reconfig_notify()?


> Another thought is it would be nice if we could have the best of both
> worlds such that the tracepoints were pr_debugs up until the ftrace
> early_initcall. Or, I suppose we could ifdef it and make the ftrace
> tracepoints a configuration option, such that if it wasn't configured
> we implement the tracepoint functions as pr_debugs. This makes early
> boot an option. Just spit balling ideas.

An overly complex solution.  This is just debug.  Worst case alternative
is that the patches live on, out of tree.  So nope.


> 
> -Tyrel
> 
>>
>> As far as I know, the of_reconfig_notify() could remain an
>> ftrace instrumented function.  But now that the only thing
>> that would be ftrace instrumented is of_reconfig_notify(),
>> I don't see a strong justification for changing the existing
>> pr_debug() calls to an ftrace alternative.  Though I suspect
>> the original author of the patch still might desire to have
>> the "#ifdef DEBUG" surrounding the pr_debug() calls removed
>> since one of his issues was having to recompile his kernel
>> to do his debugging.
>>
>> -Frank
>>
> 
> 

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

[Frank Rowand]

On 01/25/18 15:14, Wolfram Sang wrote:
> 
>> This means that ftrace can not be used for the of_node_get(),
>> of_node_put(), and of_node_release() debug info, because
>> these functions are called before early_initcall().
> 
> For the record: You can still unbind/bind devices. This is how I
> debugged an issue.

I wasn't implying that the data wasn't usable for any use case.

The point is that using ftrace means there are use cases for the
debug information where the information will not be available.

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

[Frank Rowand]

On 01/25/18 15:12, Wolfram Sang wrote:
> Frank,
> 
> here seems to be a misunderstanding going on. I don't want to push this
> patch upstream against all odds. I merely wanted to find out what the
> status of this patch is. Because one possibility was that it had just
> been forgotten...
> 
>>> So, I thought reposting would be a good way of finding out if your
>>> concerns were addressed in the discussion or not. If I overlooked

Marking a patch as RFC (as you mention just below here) is very different
than explicitly stating something like: Frank, you had concerns with
version 1, were your concerns addressed in the thread about version 1?

You mention below that adding RFC to the title was providing the
information that I needed.  I am saying that the communication was
not clear, was implied at best, and should have be more explicit.

I actually didn't even notice that the patch title had changed from
not an RFC, to being an RFC, so the subtle clue went right over my
head.  I just treated it as I would any RFC patch.


>> Then you should have stated that there were concerns raised in the
>> discussion and asked me if my concerns were addressed.
> 
> From my perspective, I have done that:
> 
> I marked the patch as RFC. I put you on the CC list. I asked about the
> possibility of applying it. It was not very elaborate, but hey, this is
> just a simple debugging patch :)

After reading through the original patch thread, I did not think that
the issues raised had been fully addressed.  You read the thread and
thought they had.  No big deal on coming to different conclusions.

I think you and I are talking past each other a little bit.  My
comments in the email you are responding to are because I don't
think that the previous emails have been as clear as you think.
I could read between the lines and see how you think that you
were being clear.  But from my perspective, I'm asking for more
explicit statements and less implied statements.

My first real response (the response that pointed out that Rob had
made an observation / suggestion that was not responded to) was coming
from the perspective that the issues in the first thread had not been
fully addressed.

As I was writing that response, I felt that I might as well do a review,
even though I thought the previous thread was dangling.  Which led to a
lot of issues and a few more emails pointing them out.


> I totally would have accepted a high level "No, that won't fly
> because...". Or a high level "This and that would need a change". Or
> something like that. I intentionally sent this out as RFC because I know
> there is some testing missing. I wanted to know if it is worth taking
> further steps with this patch.
> 
> So, I simply wanted to know if you (still) have fundamental issues with
> the patch?

It would have been good if you had simply stated so in exactly those
words.  I did not read the original email as saying that.  I read
the original email as saying (my paraphrase) "please apply it".  You
did _not_ use the words that I paraphrased, you actually said
"So what about applying it?".  I misunderstood what you were trying
to say.  I apologize for that.


> That needs to be discussed first before we go into coding
> details. I think it is fine to not apply it if there are reasons. I'd
> like to know them, however, for a better understanding.

Too late now. :-)  I've already done the reviewing and provided all
of the reasons that are show stoppers for the patch and how to fix.

One thing that I did not mention in this thread  is that I have an
aversion to using ftrace for what is purely debugging data (which
this is) because there is a danger that trace points become user
space ABI.  That is a whole long discussion that we do not have to
have because I am not subjecting this patch to that objection.


> For me, this is a super-super-side project, so if it causes too much
> hazzle, I just leave it here and know interested people can find it
> easier now. But if it could be applied with a sane amount of effort, I
> was offering that.
> 
> Was that understandable?

I think so.  And in return?  We can always talk more at the next
conference if you want.

-Frank

> 
> Kind regards,
> 
>Wolfram
> 

Re: [PATCH v12 1/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Niklas Söderlund]

Hi again,

On 2018-01-26 01:23:58 +0100, Niklas Söderlund wrote:

[snip]

> > 
> > Furthermore, as explained in a comment I made when reviewing the VIN patch 
> > series, I wonder whether we shouldn't identify the CSI-2 receiver instances 
> > by 
> > ID the same way we do with the VIN instances (using the renesas,id 
> > property). 
> > In that case I think the endpoint numbering won't matter.
> 
> The endpoint numbering here plays no part in identify the CSI-2 receiver 
> instances nor dose it carry any other information. I still think it's 
> neat to define the binding like this as it more explicit and IMHO this 
> makes it easier to understand.

I now see that the commit message implies that they do matter but this 
is wrong. It was true before the 'renesas,id' was added to the VIN 
bindings, but as having cross dependences on bindings are bad this is no 
longer the case. I will remove that paragraph for the next version.

Sorry for the noise.

-- 
Regards,
Niklas Söderlund

Re: [PATCH v12 1/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Niklas Söderlund]

Hi Laurent,

Thanks for your comments.

On 2017-12-11 20:00:21 +0200, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Wednesday, 29 November 2017 21:32:34 EET Niklas Söderlund wrote:
> > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> > are located between the video sources (CSI-2 transmitters) and the video
> > grabbers (VIN) on Gen3 of Renesas R-Car SoC.
> > 
> > Each CSI-2 device is connected to more then one VIN device which
> 
> s/then/than/
> 
> > simultaneously can receive video from the same CSI-2 device. Each VIN
> > device can also be connected to more then one CSI-2 device. The routing
> 
> s/then/than/
> 
> > of which link are used are controlled by the VIN devices. There are only
> 
> s/link are/links are/ or s/link are/link is/
> s/are controlled/is controlled/
> 
> > a few possible routes which are set by hardware limitations, which are
> > different for each SoC in the Gen3 family.
> > 
> > To work with the limitations of routing possibilities it is necessary
> > for the DT bindings to describe which VIN device is connected to which
> > CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> > VIN device that be connected to it. To setup and to know which links are
> 
> s/that be/that is/

I agree with all spelling fixes above, will fix for next version, 
thanks.

> 
> > valid for each SoC is the responsibility of the VIN driver since the
> > register to configure it belongs to the VIN hardware.
> > 
> > Signed-off-by: Niklas Söderlund 
> > Acked-by: Rob Herring 
> > ---
> >  .../bindings/media/renesas,rcar-csi2.txt   | 105 ++
> >  MAINTAINERS|   1 +
> >  2 files changed, 106 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt new file
> > mode 100644
> > index ..688afd83bf66f8cf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > @@ -0,0 +1,105 @@
> > +Renesas R-Car MIPI CSI-2
> > +
> > +
> > +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
> 
> rcar-csi2 is the name of the driver, I would call it the "R-Car CSI-2 
> receiver 
> device" (or s/device/IP core/).

Yes "R-Car CSI-2 receiver device" sounds better.

> 
> > +family of devices. It is to be used in conjunction with the R-Car VIN
> > module,
> 
> The IP core itself doesn't have to be used with the VIN, but in R-Car SoCs it 
> is, so I would phrase it as "It is used ...".

Agreed.


> 
> > +which provides the video capture capabilities.
> > +
> > +Mandatory properties
> > +
> > + - compatible: Must be one or more of the following
> > +   - "renesas,r8a7795-csi2" for the R8A7795 device.
> > +   - "renesas,r8a7796-csi2" for the R8A7796 device.
> > +
> > + - reg: the register base and size for the device registers
> > + - interrupts: the interrupt for the device
> > + - clocks: Reference to the parent clock
> 
> Either capitalize the first word after the colon or don't, but please don't 
> mix them :-)

It's this not the new thing after camel case, mixed camel case notation?  
Yes looks terrible will fix for next version.

> 
> > +
> > +The device node shall contain two 'port' child nodes according to the
> > +bindings defined in Documentation/devicetree/bindings/media/
> > +video-interfaces.txt. Port 0 shall connect the node that is the video
> > +source for to the CSI-2.
> 
> Or simply "Port 0 shall connect to the CSI-2 source." ?
> 
> > Port 1 shall connect all the R-Car VIN
> > +modules, which can make use of the CSI-2 module.
> 
> And to be a bit more explicit, how about "Port 1 shall connect to all the R-
> Car VIN modules that have a hardware connection to the CSI-2 receiver." ?

The descriptions you provide are better, will use them in the next 
version. Thanks!

> 
> > +
> > +- Port 0 - Video source (Mandatory)
> 
> Nitpicking, I don't think you need to capitalize Mandatory.

:-)

> 
> > +   - Endpoint 0 - sub-node describing the endpoint that is the video source
> > +
> > +- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
> > +   - Endpoint 0 - sub-node describing the endpoint that is VIN0
> > +   - Endpoint 1 - sub-node describing the endpoint that is VIN1
> > +   - Endpoint 2 - sub-node describing the endpoint that is VIN2
> > +   - Endpoint 3 - sub-node describing the endpoint that is VIN3
> > +   - Endpoint 4 - sub-node describing the endpoint that is VIN4
> > +   - Endpoint 5 - sub-node describing the endpoint that is VIN5
> > +   - Endpoint 6 - sub-node describing the endpoint that is VIN6
> > +   - Endpoint 7 - sub-node describing the endpoint that is VIN7
> 
> Should we clarify that 

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

[Tyrel Datwyler]

On 01/25/2018 01:49 PM, Frank Rowand wrote:
> Hi Wolfram,
> 
> On 01/25/18 03:03, Steven Rostedt wrote:
>> On Wed, 24 Jan 2018 22:55:13 -0800
>> Frank Rowand  wrote:
>>
>>> Hi Steve,
>>
>>>
>>> Off the top of your head, can you tell me know early in the boot
>>> process a trace_event can be called and successfully provide the
>>> data to someone trying to debug early boot issues?
>>
>> The trace events are enabled by early_initcall().
> 
> < snip >
> 
> This means that ftrace can not be used for the of_node_get(),
> of_node_put(), and of_node_release() debug info, because
> these functions are called before early_initcall().  Please
> use pr_debug() for these functions.

I would argue that early boot debugging doesn't completely negate the 
usefulness of this tracing infrastructure. I get that no information is 
available in the trace up until ftrace is setup by its early_initcall, but I 
still found issues  after early boot using this patch and I would hope that it 
would be somewhat obvious if references are out of whack once the ftrace data 
becomes available. In the dynamic case on Power we often do reconfig well after 
boot on live systems which produces a lot of reference put/gets. This patch 
made it easy to identify several reference leaks and underflows in our attach 
and detach logic with the added aid of being able to turn on the stacktrace for 
each call in the ftrace data.

Another thought is it would be nice if we could have the best of both worlds 
such that the tracepoints were pr_debugs up until the ftrace early_initcall. 
Or, I suppose we could ifdef it and make the ftrace tracepoints a configuration 
option, such that if it wasn't configured we implement the tracepoint functions 
as pr_debugs. This makes early boot an option. Just spit balling ideas.

-Tyrel

> 
> As far as I know, the of_reconfig_notify() could remain an
> ftrace instrumented function.  But now that the only thing
> that would be ftrace instrumented is of_reconfig_notify(),
> I don't see a strong justification for changing the existing
> pr_debug() calls to an ftrace alternative.  Though I suspect
> the original author of the patch still might desire to have
> the "#ifdef DEBUG" surrounding the pr_debug() calls removed
> since one of his issues was having to recompile his kernel
> to do his debugging.
> 
> -Frank
> 

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

[Frank Rowand]

On 01/25/18 14:40, Tyrel Datwyler wrote:
> On 01/24/2018 10:48 PM, Frank Rowand wrote:
>> On 01/21/18 06:31, Wolfram Sang wrote:
>>> From: Tyrel Datwyler 
>>>
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>>> to node/property manipulations.
>>>
>>> With the recent upstreaming of the refcount API several device_node
>>> underflows and leaks have come to my attention in the pseries (DLPAR)
>>> dynamic logical partitioning code (ie. POWER speak for hotplugging
>>> virtual and physcial resources at runtime such as cpus or IOAs). These
>>> tracepoints provide a easy and quick mechanism for validating the
>>> reference counting of device_nodes during their lifetime.
>>>
>>> Further, when pseries lpars are migrated to a different machine we
>>> perform a live update of our device tree to bring it into alignment with
>>> the configuration of the new machine. The of_reconfig_notify trace point
>>> provides a mechanism that can be turned for debuging the device tree
>>> modifications with out having to build a custom kernel to get at the
>>> DEBUG code introduced by commit 00aa37206e1a54 ("of/reconfig: Add debug
>>> output for OF_RECONFIG notifiers").
>>>
>>> The following trace events are provided: of_node_get, of_node_put,
>>> of_node_release, and of_reconfig_notify. These trace points require a
>>
>> Please add a note that the of_reconfig_notify trace event is not an
>> added bit of debug info, but is instead replacing information that
>> was previously available via pr_debug() when DEBUG was defined.
>>
>>
>>> kernel built with ftrace support to be enabled. In a typical environment
>>> where debugfs is mounted at /sys/kernel/debug the entire set of
>>> tracepoints can be set with the following:
>>>
>>>   echo "of:*" > /sys/kernel/debug/tracing/set_event
>>>
>>> or
>>>
>>>   echo 1 > /sys/kernel/debug/tracing/events/of/enable
>>>
>>> The following shows the trace point data from a DLPAR remove of a cpu
>>> from a pseries lpar:
>>>
>>> cat /sys/kernel/debug/tracing/trace | grep "POWER8@10"
>>>
>>> cpuhp/23-147   [023]    128.324827:
>>> of_node_put: refcount=5, dn->full_name=/cpus/PowerPC,POWER8@10
>>> cpuhp/23-147   [023]    128.324829:
>>> of_node_put: refcount=4, dn->full_name=/cpus/PowerPC,POWER8@10
>>> cpuhp/23-147   [023]    128.324829:
>>> of_node_put: refcount=3, dn->full_name=/cpus/PowerPC,POWER8@10
>>> cpuhp/23-147   [023]    128.324831:
>>> of_node_put: refcount=2, dn->full_name=/cpus/PowerPC,POWER8@10
>>>drmgr-7284  [009]    128.439000:
>>> of_node_put: refcount=1, dn->full_name=/cpus/PowerPC,POWER8@10
>>>drmgr-7284  [009]    128.439002:
>>> of_reconfig_notify: action=DETACH_NODE, 
>>> dn->full_name=/cpus/PowerPC,POWER8@10,
>>> prop->name=null, old_prop->name=null
>>>drmgr-7284  [009]    128.439015:
>>> of_node_put: refcount=0, dn->full_name=/cpus/PowerPC,POWER8@10
>>>drmgr-7284  [009]    128.439016:
>>> of_node_release: dn->full_name=/cpus/PowerPC,POWER8@10, dn->_flags=4
>>>
>>> Signed-off-by: Tyrel Datwyler 
>>
>> The following belongs in a list of version 2 changes, below the "---" line:
>>
>>> [wsa: fixed commit abbrev and one of the sysfs paths in commit desc,
>>> removed trailing space and fixed pointer declaration in code]
>>
>>> Signed-off-by: Wolfram Sang 
>>> ---
>>>  drivers/of/dynamic.c  | 32 ++--
>>>  include/trace/events/of.h | 93 
>>> +++
>>>  2 files changed, 105 insertions(+), 20 deletions(-)
>>>  create mode 100644 include/trace/events/of.h
>>
>> mode looks incorrect.  Existing files in include/trace/events/ are -rw-rw
>>
>>
>>> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
>>> index ab988d88704da0..b0d6ab5a35b8c6 100644
>>> --- a/drivers/of/dynamic.c
>>> +++ b/drivers/of/dynamic.c
>>> @@ -21,6 +21,9 @@ static struct device_node *kobj_to_device_node(struct 
>>> kobject *kobj)
>>> return container_of(kobj, struct device_node, kobj);
>>>  }
>>>  
>>> +#define CREATE_TRACE_POINTS
>>> +#include 
>>> +
>>>  /**
>>>   * of_node_get() - Increment refcount of a node
>>>   * @node:  Node to inc refcount, NULL is supported to simplify writing of
>>> @@ -30,8 +33,10 @@ static struct device_node *kobj_to_device_node(struct 
>>> kobject *kobj)
>>>   */
>>>  struct device_node *of_node_get(struct device_node *node)
>>>  {
>>> -   if (node)
>>> +   if (node) {
>>> kobject_get(>kobj);
>>> +   trace_of_node_get(refcount_read(>kobj.kref.refcount), 
>>> node->full_name);
>>
>> See the comment from Ron that I mentioned in my previous email.
>>
>> Also, the path has been removed from node->full_name.  Does using it here
>> still give all of the information that is desired?  Same for 

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

[Wolfram Sang]

> This means that ftrace can not be used for the of_node_get(),
> of_node_put(), and of_node_release() debug info, because
> these functions are called before early_initcall().

For the record: You can still unbind/bind devices. This is how I
debugged an issue.



signature.asc
Description: PGP signature

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

[Wolfram Sang]

Frank,

here seems to be a misunderstanding going on. I don't want to push this
patch upstream against all odds. I merely wanted to find out what the
status of this patch is. Because one possibility was that it had just
been forgotten...

> > So, I thought reposting would be a good way of finding out if your
> > concerns were addressed in the discussion or not. If I overlooked
> 
> Then you should have stated that there were concerns raised in the
> discussion and asked me if my concerns were addressed.

From my perspective, I have done that:

I marked the patch as RFC. I put you on the CC list. I asked about the
possibility of applying it. It was not very elaborate, but hey, this is
just a simple debugging patch :)

I totally would have accepted a high level "No, that won't fly
because...". Or a high level "This and that would need a change". Or
something like that. I intentionally sent this out as RFC because I know
there is some testing missing. I wanted to know if it is worth taking
further steps with this patch.

So, I simply wanted to know if you (still) have fundamental issues with
the patch? That needs to be discussed first before we go into coding
details. I think it is fine to not apply it if there are reasons. I'd
like to know them, however, for a better understanding.

For me, this is a super-super-side project, so if it causes too much
hazzle, I just leave it here and know interested people can find it
easier now. But if it could be applied with a sane amount of effort, I
was offering that.

Was that understandable?

Kind regards,

   Wolfram



signature.asc
Description: PGP signature

Re: DRM: double free in rcar_du_vsp.c

[Kieran Bingham]

Hi Volodymyr,

My apologies for the silence on this thread, but it has not been ignored.

I believe Laurent has investigated this issue, and prepared a patch
locally on his tree. However, he is currently out-of-office with travel and may
not find time to reply to this thread this week or next.

I suspect after a bit of testing and polish he will send it out for
review/integration, or inclusion in a mainline pull-request.
--
Regards

Kieran

On 24/01/18 12:04, Volodymyr Babchuk wrote:
> 
> Looping in DRM maintainer.
> 
>> Hello,
>>
>> I have found issue with double free() in RCAR DU VSP driver. it is
>> caused by rcar_du_vsp_plane_atomic_duplicate_state(), which duplicates
>> struct rcar_du_vsp_plane_state. This struct holds sg_tables which are
>> then freed in rcar_du_vsp_plane_cleanup_fb(). This function is called
>> for every rcar_du_vsp_plane_state, so it calls sg_free_table() twice for
>> the same sg_table.
>>
>> I'm not familiar with DRM, so I can't say why this does not occur every
>> time, but this bug caused problems on our setup from time to time. Looks
>> like it occurs only under heavy system load.
>>
>> As I said, I'm not good in DRM, so I don't know the proper fix. But you
>> can find workaround at [1]. I don't know how good it is, but at least
>> it resolved issue on our setup. If drm guys think that this fix is fine
>> enough, I can push it to the  ML for a proper review.
>>
>> [1]
>> https://github.com/lorc/linux/commit/80155506d3499273155366a1d263a81baface718
>>
>> Cheers,
>> -- 
>> Volodymyr Babchuk
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

[Frank Rowand]

Hi Wolfram,

On 01/25/18 03:03, Steven Rostedt wrote:
> On Wed, 24 Jan 2018 22:55:13 -0800
> Frank Rowand  wrote:
> 
>> Hi Steve,
> 
>>
>> Off the top of your head, can you tell me know early in the boot
>> process a trace_event can be called and successfully provide the
>> data to someone trying to debug early boot issues?
> 
> The trace events are enabled by early_initcall().

< snip >

This means that ftrace can not be used for the of_node_get(),
of_node_put(), and of_node_release() debug info, because
these functions are called before early_initcall().  Please
use pr_debug() for these functions.

As far as I know, the of_reconfig_notify() could remain an
ftrace instrumented function.  But now that the only thing
that would be ftrace instrumented is of_reconfig_notify(),
I don't see a strong justification for changing the existing
pr_debug() calls to an ftrace alternative.  Though I suspect
the original author of the patch still might desire to have
the "#ifdef DEBUG" surrounding the pr_debug() calls removed
since one of his issues was having to recompile his kernel
to do his debugging.

-Frank

Re: [PATCH v2] v4l: async: Protect against double notifier registrations

[Kieran Bingham]

Hi Geert,

Thanks for the review

On 17/01/18 08:00, Geert Uytterhoeven wrote:
> Hi Kieran,
> 
> On Wed, Jan 17, 2018 at 12:47 AM, Kieran Bingham
>  wrote:
>> From: Kieran Bingham 
>>
>> It can be easy to attempt to register the same notifier twice
>> in mis-handled error cases such as working with -EPROBE_DEFER.
>>
>> This results in odd kernel crashes where the notifier_list becomes
>> corrupted due to adding the same entry twice.
>>
>> Protect against this so that a developer has some sense of the pending
>> failure, and use a WARN_ON to identify the fault.
>>
>> Signed-off-by: Kieran Bingham 
> 
> Thanks for your patch!
> 
> However, I have several comments:
>   1. Instead of walking notifier_list (O(n)), can't you just check if
>  notifier.list is part of a list or not (O(1))?

Not safely as far as I can see: (unless you know better)

Looks like I'd have to at least check something like the following:
  notifier->next != LIST_POISON1 && notifier->next != NULL &&
  notifier->prev != LIST_POISON2 && notifier->prev != NULL &&
  notifier->next != notifier->prev

Although - that doesn't count the possibility that the struct list_head in the
object being added is essentially un-initialised before being added to the list
- so it could technically contain any value ...

(Looking forward to being told I'm completely missing something obvious here...)


>   2. Isn't notifier usually (always?) allocated dynamically, so if will be a
>  different pointer after a previous -EPROBE_DEFER anyway?

Nope. The notifier can be part of the device context structure to reduce
allocations.



>   3. If you enable CONFIG_DEBUG_LIST, it should scream, too.

Aha - maybe that was my missing link. -E_NOT_ENOUGH_DEBUG_ENABLED.

Although I've just looked through the code that checks against a double entry.
It may have helped me find my bug in fact, but I think that would only fire if
the entry tried to add twice consecutively, which certainly wouldn't be
guaranteed if a driver returned with -EPROBE_DEFER.

So - I've just tested that if you have A B C and HEAD,

list_add(A, HEAD);
list_add(A, HEAD);
  // would fire in __list_add_valid as (new == prev || new == next)

However,

list_add(A, HEAD);
list_add(B, HEAD);
list_add(C, HEAD);
list_add(B, HEAD);

Will not catch this double-add-B in __list_add_valid(), and will generate an
infinitely looping list if you try to then walk it with list_for_each_entry()

(As demonstrated by the attached list-test.c module which I used to test this)

Oh what fun :D

--
Kieran


> 
>> --- a/drivers/media/v4l2-core/v4l2-async.c
>> +++ b/drivers/media/v4l2-core/v4l2-async.c
>> @@ -374,17 +374,26 @@ static int __v4l2_async_notifier_register(struct 
>> v4l2_async_notifier *notifier)
>> struct device *dev =
>> notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL;
>> struct v4l2_async_subdev *asd;
>> +   struct v4l2_async_notifier *n;
>> int ret;
>> int i;
>>
>> if (notifier->num_subdevs > V4L2_MAX_SUBDEVS)
>> return -EINVAL;
>>
>> +   mutex_lock(_lock);
>> +
>> +   /* Avoid re-registering a notifier. */
>> +   list_for_each_entry(n, _list, list) {
>> +   if (WARN_ON(n == notifier)) {
>> +   ret = -EEXIST;
>> +   goto err_unlock;
>> +   }
>> +   }
>> +
>> INIT_LIST_HEAD(>waiting);
>> INIT_LIST_HEAD(>done);
>>
>> -   mutex_lock(_lock);
>> -
>> for (i = 0; i < notifier->num_subdevs; i++) {
>> asd = notifier->subdevs[i];
> 
> 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
> 

#include 
#include 
#include 


struct item {
	struct list_head list;
	int i;
};

struct item items[5];

int __init helloworld_init(void)
{
	int a;
	struct list_head head;
	struct item * ob;
	bool catch_double_add = 1;

	INIT_LIST_HEAD();

	printk("Hello World !\n");

	for (a = 0; a < 5; a++) {
		items[a].i = a;
		list_add([a].list, );
	}

	for (a = 0; a < 5; a++)
		printk("Item[%d] = %d\n", a, items[a].i);

	list_for_each_entry(ob, , list) {
		printk("ob = %d\n", ob->i);
	}

	if (catch_double_add)
		list_add([4].list, );
	else
		list_add([2].list, );

	list_for_each_entry(ob, , list) {
		printk("ob = %d\n", ob->i);
	}

	return 0;
}

void __exit helloworld_exit(void)
{
	pr_info("Goodbye cruel world...\n");
}

module_init(helloworld_init);
module_exit(helloworld_exit);
MODULE_LICENSE("GPL");

[RFC 36/37] ARM: dts: iwg20m: Add watchdog support to SoM dtsi

[Fabrizio Castro]

This patch enables the watchdog from within the iwg20m SoM dtsi.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi 
b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index 1d3e950..d364685 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -91,6 +91,11 @@
};
 };
 
+ {
+   timeout-sec = <60>;
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.7.4

[RFC 35/37] ARM: dts: r8a7794: Add watchdog support to SoC dtsi

[Fabrizio Castro]

This commit adds watchdog support to the r8a7794 dtsi.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7794.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 9309887..5f9e6d3 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -251,6 +251,16 @@
reg = <0 0xe616 0 0x0100>;
};
 
+   rwdt: watchdog@e602 {
+   compatible = "renesas,r8a7794-wdt",
+"renesas,rcar-gen2-wdt";
+   reg = <0 0xe602 0 0x0c>;
+   clocks = < CPG_MOD 402>;
+   power-domains = < R8A7794_PD_ALWAYS_ON>;
+   resets = < 402>;
+   status = "disabled";
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7794-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
2.7.4

[RFC 37/37] ARM: dts: iwg22m: Add watchdog support to SoM dtsi

[Fabrizio Castro]

This patch enables the watchdog from within the iwg20m SoM dtsi.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi 
b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
index 8d0a392b..29b6e10 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
+++ b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
@@ -91,6 +91,11 @@
};
 };
 
+ {
+   timeout-sec = <60>;
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.7.4

[RFC 34/37] ARM: dts: r8a7791: Add watchdog support to SoC dtsi

[Fabrizio Castro]

This commit adds watchdog support to the r8a7791 dtsi.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7791.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 09d1e4f..dacec25 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -289,6 +289,16 @@
reg = <0 0xe616 0 0x0100>;
};
 
+   rwdt: watchdog@e602 {
+   compatible = "renesas,r8a7791-wdt",
+"renesas,rcar-gen2-wdt";
+   reg = <0 0xe602 0 0x0c>;
+   clocks = < CPG_MOD 402>;
+   power-domains = < R8A7791_PD_ALWAYS_ON>;
+   resets = < 402>;
+   status = "disabled";
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7791-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
2.7.4

[RFC 31/37] ARM: dts: r8a7743: Add watchdog support to SoC dtsi

[Fabrizio Castro]

This patch adds watchdog support to the r8a7743 SoC dtsi.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7743.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 8606955..b44f53f 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -369,6 +369,16 @@
reg = <0 0xe616 0 0x100>;
};
 
+   rwdt: watchdog@e602 {
+   compatible = "renesas,r8a7743-wdt",
+"renesas,rcar-gen2-wdt";
+   reg = <0 0xe602 0 0x0c>;
+   clocks = < CPG_MOD 402>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 402>;
+   status = "disabled";
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7743-sysc";
reg = <0 0xe618 0 0x200>;
-- 
2.7.4

[RFC 33/37] ARM: dts: r8a7790: Add watchdog support to SoC dtsi

[Fabrizio Castro]

This commit adds watchdog support to the r8a7790 dtsi.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7790.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 88ab60a..d10ae89 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -341,6 +341,16 @@
reg = <0 0xe616 0 0x0100>;
};
 
+   rwdt: watchdog@e602 {
+   compatible = "renesas,r8a7790-wdt",
+"renesas,rcar-gen2-wdt";
+   reg = <0 0xe602 0 0x0c>;
+   clocks = < CPG_MOD 402>;
+   power-domains = < R8A7790_PD_ALWAYS_ON>;
+   resets = < 402>;
+   status = "disabled";
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7790-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
2.7.4

[RFC 32/37] ARM: dts: r8a7745: Add watchdog support to SoC dtsi

[Fabrizio Castro]

This patch adds watchdog support to the r8a7745 SoC dtsi.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7745.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 9009056..bf24c2e4 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -322,6 +322,16 @@
reg = <0 0xe616 0 0x100>;
};
 
+   rwdt: watchdog@e602 {
+   compatible = "renesas,r8a7745-wdt",
+"renesas,rcar-gen2-wdt";
+   reg = <0 0xe602 0 0x0c>;
+   clocks = < CPG_MOD 402>;
+   power-domains = < R8A7745_PD_ALWAYS_ON>;
+   resets = < 402>;
+   status = "disabled";
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7745-sysc";
reg = <0 0xe618 0 0x200>;
-- 
2.7.4

[RFC 30/37] clk: renesas: r8a7794: Add rwdt clock

[Fabrizio Castro]

Add "rwdt" clock to r8a7794_mod_clks. Also, since we may need to access
the watchdog registers at any time, declare the clock as critical.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/clk/renesas/r8a7794-cpg-mssr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/renesas/r8a7794-cpg-mssr.c 
b/drivers/clk/renesas/r8a7794-cpg-mssr.c
index ec091a4..2a40bbe 100644
--- a/drivers/clk/renesas/r8a7794-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7794-cpg-mssr.c
@@ -121,6 +121,7 @@ static const struct mssr_mod_clk r8a7794_mod_clks[] 
__initconst = {
DEF_MOD("cmt1",  329,   R8A7794_CLK_R),
DEF_MOD("usbhs-dmac0",   330,   R8A7794_CLK_HP),
DEF_MOD("usbhs-dmac1",   331,   R8A7794_CLK_HP),
+   DEF_MOD("rwdt",  402,   R8A7794_CLK_R),
DEF_MOD("irqc",  407,   R8A7794_CLK_CP),
DEF_MOD("intc-sys",  408,   R8A7794_CLK_ZS),
DEF_MOD("audio-dmac0",   502,   R8A7794_CLK_HP),
@@ -190,6 +191,7 @@ static const struct mssr_mod_clk r8a7794_mod_clks[] 
__initconst = {
 };
 
 static const unsigned int r8a7794_crit_mod_clks[] __initconst = {
+   MOD_CLK_ID(402),/* RWDT */
MOD_CLK_ID(408),/* INTC-SYS (GIC) */
 };
 
-- 
2.7.4

[RFC 29/37] clk: renesas: r8a7791/r8a7793: Add rwdt clock

[Fabrizio Castro]

Add "rwdt" clock to r8a7791_mod_clks. Also, since we may need to access
the watchdog registers at any time, declare the clock as critical.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/clk/renesas/r8a7791-cpg-mssr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/renesas/r8a7791-cpg-mssr.c 
b/drivers/clk/renesas/r8a7791-cpg-mssr.c
index c0b51f9..820b220 100644
--- a/drivers/clk/renesas/r8a7791-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7791-cpg-mssr.c
@@ -128,6 +128,7 @@ static const struct mssr_mod_clk r8a7791_mod_clks[] 
__initconst = {
DEF_MOD("cmt1",  329,   R8A7791_CLK_R),
DEF_MOD("usbhs-dmac0",   330,   R8A7791_CLK_HP),
DEF_MOD("usbhs-dmac1",   331,   R8A7791_CLK_HP),
+   DEF_MOD("rwdt",  402,   R8A7791_CLK_R),
DEF_MOD("irqc",  407,   R8A7791_CLK_CP),
DEF_MOD("intc-sys",  408,   R8A7791_CLK_ZS),
DEF_MOD("audio-dmac1",   501,   R8A7791_CLK_HP),
@@ -209,6 +210,7 @@ static const struct mssr_mod_clk r8a7791_mod_clks[] 
__initconst = {
 };
 
 static const unsigned int r8a7791_crit_mod_clks[] __initconst = {
+   MOD_CLK_ID(402),/* RWDT */
MOD_CLK_ID(408),/* INTC-SYS (GIC) */
 };
 
-- 
2.7.4

[RFC 26/37] clk: renesas: r8a7743: Add rwdt clock

[Fabrizio Castro]

Add "rwdt" clock to r8a7743_mod_clks. Also, since we may need to access
the watchdog registers at any time, declare the clock as critical.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/clk/renesas/r8a7743-cpg-mssr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/renesas/r8a7743-cpg-mssr.c 
b/drivers/clk/renesas/r8a7743-cpg-mssr.c
index 6dc0b30..d3c8b1e 100644
--- a/drivers/clk/renesas/r8a7743-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7743-cpg-mssr.c
@@ -117,6 +117,7 @@ static const struct mssr_mod_clk r8a7743_mod_clks[] 
__initconst = {
DEF_MOD("cmt1",  329,   R8A7743_CLK_R),
DEF_MOD("usbhs-dmac0",   330,   R8A7743_CLK_HP),
DEF_MOD("usbhs-dmac1",   331,   R8A7743_CLK_HP),
+   DEF_MOD("rwdt",  402,   R8A7743_CLK_R),
DEF_MOD("irqc",  407,   R8A7743_CLK_CP),
DEF_MOD("intc-sys",  408,   R8A7743_CLK_ZS),
DEF_MOD("audio-dmac1",   501,   R8A7743_CLK_HP),
@@ -195,6 +196,7 @@ static const struct mssr_mod_clk r8a7743_mod_clks[] 
__initconst = {
 };
 
 static const unsigned int r8a7743_crit_mod_clks[] __initconst = {
+   MOD_CLK_ID(402),/* RWDT */
MOD_CLK_ID(408),/* INTC-SYS (GIC) */
 };
 
-- 
2.7.4

[RFC 24/37] watchdog: renesas_wdt_gen2: Add Gen2 specific driver

[Fabrizio Castro]

R-Car Gen2 (and RZ/G1) platforms need some tweaking for SMP and watchdog
to coexist nicely.
This new driver is based on top of Wolfram Sang's driver
(drivers/watchdog/renesas_wdt.c), and it contains the quirks necessary
for R-Car Gen2 and RZ/G1 to work properly and in harmony with the rest of
the system. In particular, the driver:
* expects the device clock to be ON all the time,
* "pauses" the watchdog operation during suspend, and
* "reassures" the SMP bringup function about the availability of the
  watchdog registers.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/watchdog/Kconfig|  15 +-
 drivers/watchdog/Makefile   |   1 +
 drivers/watchdog/renesas_wdt_gen2.c | 270 
 drivers/watchdog/renesas_wdt_gen2.h |  22 +++
 4 files changed, 306 insertions(+), 2 deletions(-)
 create mode 100644 drivers/watchdog/renesas_wdt_gen2.c
 create mode 100644 drivers/watchdog/renesas_wdt_gen2.h

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ca200d1..e580c72 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -725,12 +725,23 @@ config ATLAS7_WATCHDOG
  module will be called atlas7_wdt.
 
 config RENESAS_WDT
-   tristate "Renesas WDT Watchdog"
+   tristate "Renesas R-Car Gen3 WDT Watchdog"
depends on ARCH_RENESAS || COMPILE_TEST
select WATCHDOG_CORE
help
  This driver adds watchdog support for the integrated watchdogs in the
- Renesas R-Car and other SH-Mobile SoCs (usually named RWDT or SWDT).
+ Renesas R-Car Gen3 devices.
+
+config RENESAS_WDT_GEN2
+   tristate "Renesas R-Car Gen2 and RZ/G1 WDT Watchdog"
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select WATCHDOG_CORE
+   help
+ This driver adds watchdog support for the integrated watchdogs in the
+ Renesas R-Car Gen2 and RZ/G1 devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called renesas_wdt_gen2.
 
 config RENESAS_RZAWDT
tristate "Renesas RZ/A WDT Watchdog"
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 715a210..57ab810 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_LPC18XX_WATCHDOG) += lpc18xx_wdt.o
 obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
 obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
 obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
+obj-$(CONFIG_RENESAS_WDT_GEN2) += renesas_wdt_gen2.o
 obj-$(CONFIG_RENESAS_RZAWDT) += rza_wdt.o
 obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
 obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
diff --git a/drivers/watchdog/renesas_wdt_gen2.c 
b/drivers/watchdog/renesas_wdt_gen2.c
new file mode 100644
index 000..c841636
--- /dev/null
+++ b/drivers/watchdog/renesas_wdt_gen2.c
@@ -0,0 +1,270 @@
+/*
+ * Watchdog driver for Renesas WDT watchdog
+ *
+ * Copyright (C) 2015-17 Wolfram Sang, Sang Engineering 

+ * Copyright (C) 2018Renesas Electronics 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "renesas_wdt_gen2.h"
+
+#define RWTCNT 0
+#define RWTCSRA4
+#define RWTCSRA_WOVF   BIT(4)
+#define RWTCSRA_WRFLG  BIT(5)
+#define RWTCSRA_TMEBIT(7)
+#define RWTCSRB8
+
+#define RWDT_DEFAULT_TIMEOUT   60U
+
+/*
+ * In probe, clk_rate is checked to be not more than 16 bit * biggest clock
+ * divider (12 bits). d is only a factor to fully utilize the WDT counter and
+ * will not exceed its 16 bits. Thus, no overflow, we stay below 32 bits.
+ */
+#define MUL_BY_CLKS_PER_SEC(p, d) \
+   DIV_ROUND_UP((d) * (p)->clk_rate, clk_divs[(p)->cks])
+
+/* d is 16 bit, clk_divs 12 bit -> no 32 bit overflow */
+#define DIV_BY_CLKS_PER_SEC(p, d) ((d) * clk_divs[(p)->cks] / (p)->clk_rate)
+
+static const unsigned int clk_divs[] = { 1, 4, 16, 32, 64, 128, 1024, 4096 };
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+   __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct rwdt_priv {
+   void __iomem *base;
+   struct watchdog_device wdev;
+   unsigned long clk_rate;
+   bool enabled;
+   u8 cks;
+};
+
+static void rwdt_write(struct rwdt_priv *priv, u32 val, unsigned int reg)
+{
+   if (reg == RWTCNT)
+   val |= 0x5a5a;
+   else
+   val |= 0xa5a5a500;
+
+   writel_relaxed(val, priv->base + reg);
+}
+
+static int rwdt_init_timeout(struct 

[RFC 25/37] ARM: shmobile: defconfig: Enable RENESAS_WDT_GEN2

[Fabrizio Castro]

R-Car Gen2 and RZ/G1 platforms come with a watchdog IP, therefore enable
its driver by default.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 578434c..f25bd1c 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -132,6 +132,7 @@ CONFIG_CPU_THERMAL=y
 CONFIG_RCAR_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_DA9063_WATCHDOG=y
+CONFIG_RENESAS_WDT_GEN2=y
 CONFIG_MFD_AS3711=y
 CONFIG_MFD_DA9063=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
-- 
2.7.4

[RFC 28/37] clk: renesas: r8a7790: Add rwdt clock

[Fabrizio Castro]

Add "rwdt" clock to r8a7790_mod_clks. Also, since we may need to access
the watchdog registers at any time, declare the clock as critical.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/clk/renesas/r8a7790-cpg-mssr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/renesas/r8a7790-cpg-mssr.c 
b/drivers/clk/renesas/r8a7790-cpg-mssr.c
index 46bb55b..f936cb7 100644
--- a/drivers/clk/renesas/r8a7790-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7790-cpg-mssr.c
@@ -140,6 +140,7 @@ static const struct mssr_mod_clk r8a7790_mod_clks[] 
__initconst = {
DEF_MOD("cmt1",  329,   R8A7790_CLK_R),
DEF_MOD("usbhs-dmac0",   330,   R8A7790_CLK_HP),
DEF_MOD("usbhs-dmac1",   331,   R8A7790_CLK_HP),
+   DEF_MOD("rwdt",  402,   R8A7790_CLK_R),
DEF_MOD("irqc",  407,   R8A7790_CLK_CP),
DEF_MOD("intc-sys",  408,   R8A7790_CLK_ZS),
DEF_MOD("audio-dmac1",   501,   R8A7790_CLK_HP),
@@ -211,6 +212,7 @@ static const struct mssr_mod_clk r8a7790_mod_clks[] 
__initconst = {
 };
 
 static const unsigned int r8a7790_crit_mod_clks[] __initconst = {
+   MOD_CLK_ID(402),/* RWDT */
MOD_CLK_ID(408),/* INTC-SYS (GIC) */
 };
 
-- 
2.7.4

[RFC 27/37] clk: renesas: r8a7745: Add rwdt clock

[Fabrizio Castro]

Add "rwdt" clock to r8a7745_mod_clks. Also, since we may need to access
the watchdog registers at any time, declare the clock as critical.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/clk/renesas/r8a7745-cpg-mssr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/renesas/r8a7745-cpg-mssr.c 
b/drivers/clk/renesas/r8a7745-cpg-mssr.c
index 2859504..87f5a36 100644
--- a/drivers/clk/renesas/r8a7745-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7745-cpg-mssr.c
@@ -114,6 +114,7 @@ static const struct mssr_mod_clk r8a7745_mod_clks[] 
__initconst = {
DEF_MOD("cmt1",  329,   R8A7745_CLK_R),
DEF_MOD("usbhs-dmac0",   330,   R8A7745_CLK_HP),
DEF_MOD("usbhs-dmac1",   331,   R8A7745_CLK_HP),
+   DEF_MOD("rwdt",  402,   R8A7745_CLK_R),
DEF_MOD("irqc",  407,   R8A7745_CLK_CP),
DEF_MOD("intc-sys",  408,   R8A7745_CLK_ZS),
DEF_MOD("audio-dmac0",   502,   R8A7745_CLK_HP),
@@ -180,6 +181,7 @@ static const struct mssr_mod_clk r8a7745_mod_clks[] 
__initconst = {
 };
 
 static const unsigned int r8a7745_crit_mod_clks[] __initconst = {
+   MOD_CLK_ID(402),/* RWDT */
MOD_CLK_ID(408),/* INTC-SYS (GIC) */
 };
 
-- 
2.7.4

[RFC 23/37] ARM: shmobile: rcar-gen2: Export shmobile_set_wdt_clock_status function

[Fabrizio Castro]

This patch exposes a function to set the value of variable
"shmobile_wdt_clock_status" so that the watchdog driver may communicate
critical information to the SMP bring up assembly routine.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/mach-shmobile/common.h   |  1 +
 arch/arm/mach-shmobile/pm-rcar-gen2.c | 16 +++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index a8fa4f7..e4ffca8 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -5,6 +5,7 @@
 extern void shmobile_init_cntvoff(void);
 extern void shmobile_init_delay(void);
 extern void shmobile_boot_vector(void);
+extern unsigned long shmobile_wdt_clock_status;
 extern unsigned long shmobile_boot_fn;
 extern unsigned long shmobile_boot_size;
 extern void shmobile_smp_boot(void);
diff --git a/arch/arm/mach-shmobile/pm-rcar-gen2.c 
b/arch/arm/mach-shmobile/pm-rcar-gen2.c
index e5f215c..cfdc3cd 100644
--- a/arch/arm/mach-shmobile/pm-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/pm-rcar-gen2.c
@@ -50,6 +50,16 @@ static inline u32 phys_to_sbar(phys_addr_t addr)
 #define SYSCIER 0x0c
 #define SYSCIMR 0x10
 
+static void __iomem *shmobile_boot_vector_start;
+static unsigned long clock_status;
+
+void shmobile_set_wdt_clock_status(unsigned long value)
+{
+   memcpy_toio(shmobile_boot_vector_start + clock_status,
+   , sizeof(value));
+}
+EXPORT_SYMBOL(shmobile_set_wdt_clock_status);
+
 #if defined(CONFIG_SMP)
 
 static void __init rcar_gen2_sysc_init(u32 syscier)
@@ -120,8 +130,12 @@ void __init rcar_gen2_pm_init(void)
if (!p)
return;
 
+   shmobile_boot_vector_start = p;
+   clock_status = (_wdt_clock_status -
+   (unsigned long *)shmobile_boot_vector) *
+   sizeof(shmobile_wdt_clock_status);
+
memcpy_toio(p, shmobile_boot_vector, shmobile_boot_size);
-   iounmap(p);
 
/* setup reset vectors */
p = ioremap_nocache(RST, 0x63);
-- 
2.7.4

[RFC 17/37] arm64: dts: renesas: r8a7795: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index ce85704..853ca99 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -438,7 +438,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a7795-rst";
+   compatible = "renesas,r8a7795-rst",
+"renesas,rcar-gen3-rst";
reg = <0 0xe616 0 0x0200>;
};
 
-- 
2.7.4

[RFC 10/37] soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2

[Fabrizio Castro]

This patch allows for platform specific quirks as some of the SoC need
further customization for the watchdog to work properly, like for R-Car
Gen2 and for RZ/G.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/soc/renesas/rcar-rst.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
index f7a0d54..5f52aea 100644
--- a/drivers/soc/renesas/rcar-rst.c
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -13,8 +13,18 @@
 #include 
 #include 
 
+#define WDTRSTCR_RESET 0xA55A0002
+#define WDTRSTCR   0x0054
+
+static int gen2_configuration(void __iomem *base)
+{
+   iowrite32(WDTRSTCR_RESET, base + WDTRSTCR);
+   return 0;
+}
+
 struct rst_config {
-   unsigned int modemr;/* Mode Monitoring Register Offset */
+   unsigned int modemr;/* Mode Monitoring Register Offset */
+   int (*configure)(void *base);   /* Platform specific configuration */
 };
 
 static const struct rst_config rcar_rst_gen1 __initconst = {
@@ -23,6 +33,7 @@ static const struct rst_config rcar_rst_gen1 __initconst = {
 
 static const struct rst_config rcar_rst_gen2 __initconst = {
.modemr = 0x60,
+   .configure = gen2_configuration,
 };
 
 static const struct rst_config rcar_rst_gen3 __initconst = {
@@ -79,6 +90,14 @@ static int __init rcar_rst_init(void)
rcar_rst_base = base;
cfg = match->data;
saved_mode = ioread32(base + cfg->modemr);
+   if (cfg->configure) {
+   error = cfg->configure(base);
+   if (error) {
+   pr_warn("%pOF: Cannot run SoC specific configuration\n",
+   np);
+   goto out_put;
+   }
+   }
 
pr_debug("%pOF: MODE = 0x%08x\n", np, saved_mode);
 
-- 
2.7.4

[RFC 16/37] ARM: dts: r8a7794: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7794.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index a5a23e9..9309887 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -246,7 +246,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a7794-rst";
+   compatible = "renesas,r8a7794-rst",
+"renesas,rcar-gen2-rst";
reg = <0 0xe616 0 0x0100>;
};
 
-- 
2.7.4

[RFC 21/37] dt-bindings: watchdog: renesas-wdt: Add R-Car Gen2 support

[Fabrizio Castro]

This commit documents the compatibility with R-Car Gen2 and RZ/G
devices by defining the generifc compatible string "renesas,rcar-gen2-wdt".

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
index bf6d1ca..436dca5 100644
--- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
@@ -1,17 +1,20 @@
 Renesas Watchdog Timer (WDT) Controller
 
 Required properties:
-- compatible : Should be "renesas,-wdt", and
-  "renesas,rcar-gen3-wdt" or "renesas,rza-wdt" as fallback.
+ - compatible : Must be "renesas,-wdt", followed by a generic
+   fallback compatible string when compatible with the generic
+   version.
   Examples with soctypes are:
+- "renesas,r8a7743-wdt" (RZ/G1M)
+- "renesas,r8a7745-wdt" (RZ/G1E)
 - "renesas,r8a7795-wdt" (R-Car H3)
 - "renesas,r8a7796-wdt" (R-Car M3-W)
 - "renesas,r8a77995-wdt" (R-Car D3)
 - "renesas,r7s72100-wdt" (RZ/A1)
+   The generic compatible string must be:
+- "renesas,rcar-gen2-wdt" for R-Car Gen2 and RZ/G
+- "renesas,rcar-gen3-wdt" for R-Car Gen3
 
-  When compatible with the generic version, nodes must list the SoC-specific
-  version corresponding to the platform first, followed by the generic
-  version.
 
 - reg : Should contain WDT registers location and length
 - clocks : the clock feeding the watchdog timer.
-- 
2.7.4

[RFC 19/37] arm64: dts: renesas: r8a77970: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 566a7f7..0fda66f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -113,7 +113,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a77970-rst";
+   compatible = "renesas,r8a77970-rst",
+"renesas,rcar-gen3-rst";
reg = <0 0xe616 0 0x200>;
};
 
-- 
2.7.4

[RFC 18/37] arm64: dts: renesas: r8a7796: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f8e9313..7b347d8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -510,7 +510,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a7796-rst";
+   compatible = "renesas,r8a7796-rst",
+"renesas,rcar-gen3-rst";
reg = <0 0xe616 0 0x0200>;
};
 
-- 
2.7.4

[RFC 22/37] watchdog: renesas_wdt: Add restart support

[Fabrizio Castro]

This commit extends the driver to add restart support by implementing
the restart callback to trigger the watchdog as quickly as possible.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/watchdog/renesas_wdt.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index 831ef83..120ddac 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -107,6 +107,24 @@ static unsigned int rwdt_get_timeleft(struct 
watchdog_device *wdev)
return DIV_BY_CLKS_PER_SEC(priv, 65536 - val);
 }
 
+static int rwdt_restart(struct watchdog_device *wdev, unsigned long action,
+   void *data)
+{
+   struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
+
+   pm_runtime_get_sync(wdev->parent);
+
+   rwdt_write(priv, 0x00, RWTCSRB);
+   rwdt_write(priv, 0x00, RWTCSRA);
+   rwdt_write(priv, 0x, RWTCNT);
+
+   while (readb_relaxed(priv->base + RWTCSRA) & RWTCSRA_WRFLG)
+   cpu_relax();
+
+   rwdt_write(priv, 0x80, RWTCSRA);
+   return 0;
+}
+
 static const struct watchdog_info rwdt_ident = {
.options = WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT,
.identity = "Renesas WDT Watchdog",
@@ -118,6 +136,7 @@ static const struct watchdog_ops rwdt_ops = {
.stop = rwdt_stop,
.ping = rwdt_init_timeout,
.get_timeleft = rwdt_get_timeleft,
+   .restart = rwdt_restart,
 };
 
 static int rwdt_probe(struct platform_device *pdev)
-- 
2.7.4

[RFC 20/37] arm64: dts: renesas: r8a77995: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 23f763b..2cd8ef0 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -196,7 +196,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a77995-rst";
+   compatible = "renesas,r8a77995-rst",
+"renesas,rcar-gen3-rst";
reg = <0 0xe616 0 0x0200>;
};
 
-- 
2.7.4

[RFC 14/37] ARM: dts: r8a7790: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7790.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 8b34636..88ab60a 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -336,7 +336,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a7790-rst";
+   compatible = "renesas,r8a7790-rst",
+"renesas,rcar-gen2-rst";
reg = <0 0xe616 0 0x0100>;
};
 
-- 
2.7.4

[RFC 15/37] ARM: dts: r8a7791: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7791.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 00932d9..09d1e4f 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -284,7 +284,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a7791-rst";
+   compatible = "renesas,r8a7791-rst",
+"renesas,rcar-gen2-rst";
reg = <0 0xe616 0 0x0100>;
};
 
-- 
2.7.4

[RFC 13/37] ARM: dts: r8a7745: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7745.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 32e8784..9009056 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -317,7 +317,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a7745-rst";
+   compatible = "renesas,r8a7745-rst",
+"renesas,rcar-gen2-rst";
reg = <0 0xe616 0 0x100>;
};
 
-- 
2.7.4

[RFC 07/37] ARM: dts: r8a7793: Adjust SMP routine size

[Fabrizio Castro]

This patch adjusts the definition of the SMP routine size according
to the latest changes made by commit:
"ARM: shmobile: Add watchdog support"

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7793.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index aa7d779..ca684d0 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -392,7 +392,7 @@
 
smp-sram@0 {
compatible = "renesas,smp-sram";
-   reg = <0 0x10>;
+   reg = <0 0x64>;
};
};
 
-- 
2.7.4

[RFC 12/37] ARM: dts: r8a7743: Use fallback rst compatible string

[Fabrizio Castro]

Add the generic fallback compatible string for the rst node.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7743.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index d5834b6..8606955 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -364,7 +364,8 @@
};
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a7743-rst";
+   compatible = "renesas,r8a7743-rst",
+"renesas,rcar-gen2-rst";
reg = <0 0xe616 0 0x100>;
};
 
-- 
2.7.4

[RFC 06/37] ARM: dts: r8a7792: Adjust SMP routine size

[Fabrizio Castro]

This patch adjusts the definition of the SMP routine size according
to the latest changes made by commit:
"ARM: shmobile: Add watchdog support"

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7792.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 268987f..7f9213c 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -341,7 +341,7 @@
 
smp-sram@0 {
compatible = "renesas,smp-sram";
-   reg = <0 0x10>;
+   reg = <0 0x64>;
};
};
 
-- 
2.7.4

[RFC 05/37] ARM: dts: r8a7791: Adjust SMP routine size

[Fabrizio Castro]

This patch adjusts the definition of the SMP routine size according
to the latest changes made by commit:
"ARM: shmobile: Add watchdog support"

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7791.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index dc65935..00932d9 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -407,7 +407,7 @@
 
smp-sram@0 {
compatible = "renesas,smp-sram";
-   reg = <0 0x10>;
+   reg = <0 0x64>;
};
};
 
-- 
2.7.4

[RFC 08/37] ARM: dts: r8a7794: Adjust SMP routine size

[Fabrizio Castro]

This patch adjusts the definition of the SMP routine size according
to the latest changes made by commit:
"ARM: shmobile: Add watchdog support"

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7794.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index d588efa..a5a23e9 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -348,7 +348,7 @@
 
smp-sram@0 {
compatible = "renesas,smp-sram";
-   reg = <0 0x10>;
+   reg = <0 0x64>;
};
};
 
-- 
2.7.4

[RFC 11/37] soc: renesas: rcar-rst: Document generic compatible strings

[Fabrizio Castro]

>From now on, devices compatible with the generic compatible strings
documented by this commit don't need to modify the corresponding driver
anymore.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 Documentation/devicetree/bindings/reset/renesas,rst.txt | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt 
b/Documentation/devicetree/bindings/reset/renesas,rst.txt
index a8014f3..2602a19 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rst.txt
+++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
@@ -11,7 +11,10 @@ following functions:
 
 
 Required properties:
-  - compatible: Should be
+  - compatible: Should be a SoC specific string, followed by a generic
+   fallback compatible string when compatible with the generic
+   version.
+   The SoC specific compatible string should be:
  - "renesas,-reset-wdt" for R-Car Gen1,
  - "renesas,-rst" for R-Car Gen2 and Gen3, and RZ/G
Examples with soctypes are:
@@ -28,12 +31,16 @@ Required properties:
  - "renesas,r8a7796-rst" (R-Car M3-W)
  - "renesas,r8a77970-rst" (R-Car V3M)
  - "renesas,r8a77995-rst" (R-Car D3)
+   The generic compatible string should be:
+ - "renesas,rcar-gen1-rst" for R-Car Gen1
+ - "renesas,rcar-gen2-rst" for R-Car Gen2 and RZ/G
+ - "renesas,rcar-gen3-rst" for R-Car Gen3
   - reg: Address start and address range for the device.
 
 
 Example:
 
rst: reset-controller@e616 {
-   compatible = "renesas,r8a7795-rst";
+   compatible = "renesas,r8a7795-rst", "renesas,rcar-gen3-rst";
reg = <0 0xe616 0 0x0200>;
};
-- 
2.7.4

[RFC 09/37] soc: renesas: rcar-rst: Add generic compatible strings

[Fabrizio Castro]

This commit introduces generic compatible strings to use as fallback,
so that devices compatible with the generic implementation may avoid
changing the driver.

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/soc/renesas/rcar-rst.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
index 3316b02..f7a0d54 100644
--- a/drivers/soc/renesas/rcar-rst.c
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -25,8 +25,16 @@ static const struct rst_config rcar_rst_gen2 __initconst = {
.modemr = 0x60,
 };
 
+static const struct rst_config rcar_rst_gen3 __initconst = {
+   .modemr = 0x60,
+};
+
 static const struct of_device_id rcar_rst_matches[] __initconst = {
-   /* RZ/G is handled like R-Car Gen2 */
+   /* generic compatible strings */
+   { .compatible = "renesas,rcar-gen1-rst", .data = _rst_gen1 },
+   { .compatible = "renesas,rcar-gen2-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,rcar-gen3-rst", .data = _rst_gen3 },
+   /* RZ/G */
{ .compatible = "renesas,r8a7743-rst", .data = _rst_gen2 },
{ .compatible = "renesas,r8a7745-rst", .data = _rst_gen2 },
/* R-Car Gen1 */
@@ -38,11 +46,11 @@ static const struct of_device_id rcar_rst_matches[] 
__initconst = {
{ .compatible = "renesas,r8a7792-rst", .data = _rst_gen2 },
{ .compatible = "renesas,r8a7793-rst", .data = _rst_gen2 },
{ .compatible = "renesas,r8a7794-rst", .data = _rst_gen2 },
-   /* R-Car Gen3 is handled like R-Car Gen2 */
-   { .compatible = "renesas,r8a7795-rst", .data = _rst_gen2 },
-   { .compatible = "renesas,r8a7796-rst", .data = _rst_gen2 },
-   { .compatible = "renesas,r8a77970-rst", .data = _rst_gen2 },
-   { .compatible = "renesas,r8a77995-rst", .data = _rst_gen2 },
+   /* R-Car Gen3 */
+   { .compatible = "renesas,r8a7795-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a7796-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a77970-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a77995-rst", .data = _rst_gen3 },
{ /* sentinel */ }
 };
 
-- 
2.7.4

[RFC 03/37] ARM: dts: r8a7745: Adjust SMP routine size

[Fabrizio Castro]

This patch adjusts the definition of the SMP routine size according
to the latest changes made by commit:
"ARM: shmobile: Add watchdog support"

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7745.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index ddc3da2..32e8784 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -755,7 +755,7 @@
 
smp-sram@0 {
compatible = "renesas,smp-sram";
-   reg = <0 0x10>;
+   reg = <0 0x64>;
};
};
 
-- 
2.7.4

[RFC 04/37] ARM: dts: r8a7790: Adjust SMP routine size

[Fabrizio Castro]

This patch adjusts the definition of the SMP routine size according
to the latest changes made by commit:
"ARM: shmobile: Add watchdog support"

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7790.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 3bbcc0b..8b34636 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -443,7 +443,7 @@
 
smp-sram@0 {
compatible = "renesas,smp-sram";
-   reg = <0 0x10>;
+   reg = <0 0x64>;
};
};
 
-- 
2.7.4

[RFC 01/37] ARM: shmobile: Add watchdog support

[Fabrizio Castro]

On R-Car Gen2 and RZ/G1 platforms, we use the SBAR registers to make non
boot CPUs run a routine designed to bring up SMP and deal with hot plug.
The value contained in the SBAR registers is not initialized by a WDT
triggered reset, which means that after a WDT triggered reset we jump
to the SMP bring up routine, preventing the system from executing the
bootrom code.

The purpose of this patch is to jump to the bootrom code in case of a
WDT triggered reset, and keep the SMP functionality untouched.
In order to tell if the code had been called due to the WDT overflowing
we need to inspect flag WOVF from register RWTCSRA, however for this
to work smoothly we need to make sure that RWDT clock is ON.
Since it's not wise to interfere with the clock configuration from
within this routine, a flag has been put in place
(shmobile_wdt_clock_status) so that the watchdog driver can tell
shmobile_boot_vector when the clock is ON, and therefore there is no
need for shmobile_boot_vector to mess up with the clock registers.

Bit WOVF survives a watchdog triggered reset, and it is usually cleared
by the bootloader. Checking the MMU enable bit from register SCTLR
allows us to make the code a little bit more robust (just in case the
bit wasn't cleared up), as right after a reset the MMU is disabled,
and when Linux is running the MMU is enabled. Also, accessing RWTCSRA
physical address is safe when the MMU is down.

SMP bringup, CPU hot plug, and suspend to RAM work as normal.

Since shmobile_boot_vector has become bigger, "reg" property of nodes
compatible with "renesas,smp-sram" now need to be set to "<0 0x64>".

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/mach-shmobile/headsmp.S | 53 
 1 file changed, 53 insertions(+)

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 32e0bf6..835bddc 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -16,6 +16,13 @@
 #include 
 #include 
 
+#define RWDT_CLOCK_ON  0xdeadbeef
+#define RWDT_CLOCK_OFF 0x
+#define SCTLR_MMU  0x01
+#define BOOTROM_ADDRESS0xE634
+#define RWTCSRA_ADDRESS 0xE6020004
+#define RWTCSRA_WOVF   0x10
+
 /*
  * Reset vector for secondary CPUs.
  * This will be mapped at address 0 by SBAR register.
@@ -24,11 +31,57 @@
.arm
.align  12
 ENTRY(shmobile_boot_vector)
+/*
+   if (SCTLR_MMU == 1)
+   goto shmobile_smp_continue;
+*/
+   mrc p15, 0, r1, c1, c0, 0   @ r1 = SCTLR
+   and r0, r1, #SCTLR_MMU
+   cmp r0, #SCTLR_MMU
+   beq shmobile_smp_continue
+/*
+   if (shmobile_wdt_clock_status != RWDT_CLOCK_ON)
+   goto shmobile_smp_continue;
+*/
+   ldr r0, #shmobile_wdt_clock_status
+   ldr r1, #clock_on
+   cmp r0, r1
+   bne shmobile_smp_continue
+
+/*
+   if (RWTCSRA_WOVF == 0)
+   goto shmobile_smp_continue;
+*/
+   ldr r0, rwtcsra
+   mov r1, #0
+   ldrbr1, [r0]
+   and r0, r1, #RWTCSRA_WOVF
+   cmp r0, #RWTCSRA_WOVF
+   bne shmobile_smp_continue
+
+/*
+   goto bootrom;
+*/
+   ldr r0, bootrom
+   bx  r0
+
+shmobile_smp_continue:
ldr r1, 1f
bx  r1
 
 ENDPROC(shmobile_boot_vector)
 
+   .align  4
+rwtcsra:
+   .word   RWTCSRA_ADDRESS
+bootrom:
+   .word   BOOTROM_ADDRESS
+clock_on:
+   .word   RWDT_CLOCK_ON
+   .globl  shmobile_wdt_clock_status
+shmobile_wdt_clock_status:
+   .word   RWDT_CLOCK_OFF
+
.align  2
.globl  shmobile_boot_fn
 shmobile_boot_fn:
-- 
2.7.4

[RFC 02/37] ARM: dts: r8a7743: Adjust SMP routine size

[Fabrizio Castro]

This patch adjusts the definition of the SMP routine size according
to the latest changes made by commit:
"ARM: shmobile: Add watchdog support"

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
 arch/arm/boot/dts/r8a7743.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 47b62f6..d5834b6 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -973,7 +973,7 @@
 
smp-sram@0 {
compatible = "renesas,smp-sram";
-   reg = <0 0x10>;
+   reg = <0 0x64>;
};
};
 
-- 
2.7.4

[RFC 00/37] Fix watchdog on Renesas R-Car Gen2 and RZ/G1

[Fabrizio Castro]

Dear All,

while trying to add watchdog support to RZ/G1M and RZ/G1E I discovered
that it couldn't work out of the box. R-Car Gen2 and RZ/G1 are very
similar from a design perspective, and therefore the same problem is
observable on R-Car Gen2 too.

To deal with SMP on R-Car Gen2 and RZ/G1, we install a reset vector
to ICRAM1 and we program the [S]BAR registers so that when we turn ON
the non-boot CPUs they are redirected to the reset vector installed by
Linux in ICRAM1, and eventually they continue the execution to RAM,
where the SMP bring-up code will take care of the rest.
The content of the [S]BAR registers survives a watchdog triggered reset,
and as such after the watchdog fires the boot core will try and execute
the SMP bring-up code instead of jumping to the bootrom code.

This series is a proposal for a fix to the aforementioned problem.
The main strategy for the solution is to let the reset vector decide
if it needs to jump to shmobile_boot_fn or to the bootrom code.
In a watchdog triggered reset scenario, since the [S]BAR registers keep
their values, the boot CPU will jump into the newly designed reset
vector, the assembly routine will eventually test WOVF (a bit in register
RWTCSRA that indicates if the watchdog counter has overflown, the value
of this bit gets retained in this scenario), and jump to the bootrom code
which will in turn load up the bootloader, etc.
When bringing up SMP or using CPU hotplug, the reset vector will jump
to shmobile_boot_fn instead.

I think it's worth giving an overview of the implementation here to make
it easier for the reader to understand the full picture.
Patch "ARM: shmobile: Add watchdog support" modifies the reset vector,
and since the size in bytes of the reset vector changes we need to update
all of the .dtsi accordingly with patches "Adjust SMP routine size" for
the various SoC.
In order for the watchdog IP to actually trigger a reset we need to clear
bit RWDT_RSTMSK first, this leads to patches:
* "soc: renesas: rcar-rst: Add generic compatible strings",
* "soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2",
* "soc: renesas: rcar-rst: Document generic compatible strings", and
* "Use fallback rst compatible string" for the various SoC.
This RFC provides a driver specifically designed for R-Car Gen2 and
RZ/G1, its implementation may be merged with the R-Car Gen3 one instead
of being delivered by a new driver. The patches taking care of the
driver are:
* "ARM: shmobile: rcar-gen2: Export shmobile_set_wdt_clock_status function"
* "watchdog: renesas_wdt_gen2: Add Gen2 specific driver"
Patch "watchdog: renesas_wdt: Add restart support" is simply an ehancement
to the Gen3 driver.
The "Add rwdt clock" patches add the definitions required by the rwdt clock,
please note that we are declaring the rwdt clocks as critical, and that's
because having the rwdt always ON guarantees that it is (almost) always
safe to read the WOVF bit and also purges the implementation from race
conditions.
The remaining patches define the rwdt DT node for the platforms we have
tested, and finally add support watchdof to the iwg20m and iwg22m SoM.

Speaking of testing, we tested this series on top of the following boards:
* iwg20d,
* iwg22d,
* Lager (only running on the CA15s),
* Koelsh, and
* Alt

This work was rebased on top of tag renesas-devel-20180122-v4.15-rc9
from the below repository:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git

What do you guys think about this?

Any volunteer for testing this work on other platforms using the
same reset vector?

Comments welcome!

Best Regards,

Fabrizio Castro (37):
  ARM: shmobile: Add watchdog support
  ARM: dts: r8a7743: Adjust SMP routine size
  ARM: dts: r8a7745: Adjust SMP routine size
  ARM: dts: r8a7790: Adjust SMP routine size
  ARM: dts: r8a7791: Adjust SMP routine size
  ARM: dts: r8a7792: Adjust SMP routine size
  ARM: dts: r8a7793: Adjust SMP routine size
  ARM: dts: r8a7794: Adjust SMP routine size
  soc: renesas: rcar-rst: Add generic compatible strings
  soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2
  soc: renesas: rcar-rst: Document generic compatible strings
  ARM: dts: r8a7743: Use fallback rst compatible string
  ARM: dts: r8a7745: Use fallback rst compatible string
  ARM: dts: r8a7790: Use fallback rst compatible string
  ARM: dts: r8a7791: Use fallback rst compatible string
  ARM: dts: r8a7794: Use fallback rst compatible string
  arm64: dts: renesas: r8a7795: Use fallback rst compatible string
  arm64: dts: renesas: r8a7796: Use fallback rst compatible string
  arm64: dts: renesas: r8a77970: Use fallback rst compatible string
  arm64: dts: renesas: r8a77995: Use fallback rst compatible string
  dt-bindings: watchdog: renesas-wdt: Add R-Car Gen2 support
  watchdog: renesas_wdt: Add restart support
  ARM: shmobile: rcar-gen2: Export shmobile_set_wdt_clock_status
function
  watchdog: renesas_wdt_gen2: Add Gen2 specific driver
  ARM: shmobile: defconfig: Enable 

Re: [PATCH] sh: clk: Relax clk rate match test

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Jan 25, 2018 at 3:14 PM, jacopo mondi  wrote:
> On Thu, Jan 25, 2018 at 02:53:41PM +0100, Geert Uytterhoeven wrote:
>> CC linux-clk (yes I know this is about the legacy SH clock framework, but
>> the public API is/should be the same)
>>
>> On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi
>>  wrote:
>> > When asking for a clk rate to be set, the sh core clock matches only
>> > exact rate values against the calculated frequency table entries. If the
>> > rate does not match exactly the test fails, and the whole frequency
>> > table is walked, resulting in selection of the last entry, corresponding to
>> > the lowest available clock rate.
>>
>> IIUIC, the code does not select the last entry, but returns an error code,
>> which is propagated all the way up?
>>
>> > Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" 
>> > line),
>> > the calculated clock frequency 10088572 Hz gets ignored, and the clock is
>> > actually set to 5201920 Hz, which is the last available entry of the 
>> > frequencies
>> > table.
>>
>> Perhaps 5201920 is just the default (or old value)?
>>
>> > Relax the clock frequency match test, allowing selection of clock rates
>> > immediately slower than the required one.
>> >
>> > Signed-off-by: Jacopo Mondi 
>> >
>> > ---
>> > Hello renesas lists,
>> >
>> > I'm now working on handling frame rate for the ov7720 image sensor to have 
>> > that
>> > driver accepted as part of v4l2. The sensor is installed on on Migo-R 
>> > board.
>> > In order to properly calculate pixel clock and the framerate I noticed the
>> > clock signal fed to the sensor from the SH7722 chip was always the lowest
>> > available one.
>> >
>> > This patch fixes the issues and allows me to properly select which clock
>> > frequency supply to the sensor, which according to datasheet does not 
>> > support
>> > input clock frequencies slower than 10MHz (but works anyhow).
>> >
>> > As all patches for SH architecture I wonder where they should be picked up 
>> > from,
>> > as SH seems not maintained at the moment.
>> >
>> > Thanks
>> >j
>> >
>> > ---
>> >  drivers/sh/clk/core.c | 9 ++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
>> > index 92863e3..d2cb94c 100644
>> > --- a/drivers/sh/clk/core.c
>> > +++ b/drivers/sh/clk/core.c
>> > @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
>> >  {
>> > struct cpufreq_frequency_table *pos;
>> >
>> > -   cpufreq_for_each_valid_entry(pos, freq_table)
>> > -   if (pos->frequency == rate)
>> > -   return pos - freq_table;
>> > +   cpufreq_for_each_valid_entry(pos, freq_table) {
>> > +   if (pos->frequency > rate)
>> > +   continue;
>>
>> This assumes all frequency tables are sorted.
>>
>> Shouldn't you pick the closest frequency?
>>
>> However, that's what clk_rate_table_round() does, which is called from
>> sh_clk_div_round_rate(), and thus already used as .round_rate:
>>
>> static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
>> .recalc = sh_clk_div_recalc,
>> .set_rate   = sh_clk_div_set_rate,
>> .round_rate = sh_clk_div_round_rate,
>> .enable = sh_clk_div_enable,
>> .disable= sh_clk_div_disable,
>> };
>
> Does this implies clock rates should be set using clk_round_rate() and
> not clk_set_rate() if I understand this right?

Not necessarily...

Note that both cpg_div6_clock_round_rate() and cpg_div6_clock_set_rate()
in the CCF implementation for DIV6 clocks use rounding.

>> (clk_rate_table_find() is called from sh_clk_div_set_rate())
>>
>> Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
>> come from?
>
> From board initialization code, in order to provide a valid input
> clock to OV7720 sensor.

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] sh: clk: Relax clk rate match test

[jacopo mondi]

Hi Geert,

On Thu, Jan 25, 2018 at 02:53:41PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> CC linux-clk (yes I know this is about the legacy SH clock framework, but
> the public API is/should be the same)
>
> On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi
>  wrote:
> > When asking for a clk rate to be set, the sh core clock matches only
> > exact rate values against the calculated frequency table entries. If the
> > rate does not match exactly the test fails, and the whole frequency
> > table is walked, resulting in selection of the last entry, corresponding to
> > the lowest available clock rate.
>
> IIUIC, the code does not select the last entry, but returns an error code,
> which is propagated all the way up?
>
> > Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" 
> > line),
> > the calculated clock frequency 10088572 Hz gets ignored, and the clock is
> > actually set to 5201920 Hz, which is the last available entry of the 
> > frequencies
> > table.
>
> Perhaps 5201920 is just the default (or old value)?
>
> > Relax the clock frequency match test, allowing selection of clock rates
> > immediately slower than the required one.
> >
> > Signed-off-by: Jacopo Mondi 
> >
> > ---
> > Hello renesas lists,
> >
> > I'm now working on handling frame rate for the ov7720 image sensor to have 
> > that
> > driver accepted as part of v4l2. The sensor is installed on on Migo-R board.
> > In order to properly calculate pixel clock and the framerate I noticed the
> > clock signal fed to the sensor from the SH7722 chip was always the lowest
> > available one.
> >
> > This patch fixes the issues and allows me to properly select which clock
> > frequency supply to the sensor, which according to datasheet does not 
> > support
> > input clock frequencies slower than 10MHz (but works anyhow).
> >
> > As all patches for SH architecture I wonder where they should be picked up 
> > from,
> > as SH seems not maintained at the moment.
> >
> > Thanks
> >j
> >
> > ---
> >  drivers/sh/clk/core.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
> > index 92863e3..d2cb94c 100644
> > --- a/drivers/sh/clk/core.c
> > +++ b/drivers/sh/clk/core.c
> > @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
> >  {
> > struct cpufreq_frequency_table *pos;
> >
> > -   cpufreq_for_each_valid_entry(pos, freq_table)
> > -   if (pos->frequency == rate)
> > -   return pos - freq_table;
> > +   cpufreq_for_each_valid_entry(pos, freq_table) {
> > +   if (pos->frequency > rate)
> > +   continue;
>
> This assumes all frequency tables are sorted.
>
> Shouldn't you pick the closest frequency?
>
> However, that's what clk_rate_table_round() does, which is called from
> sh_clk_div_round_rate(), and thus already used as .round_rate:
>
> static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
> .recalc = sh_clk_div_recalc,
> .set_rate   = sh_clk_div_set_rate,
> .round_rate = sh_clk_div_round_rate,
> .enable = sh_clk_div_enable,
> .disable= sh_clk_div_disable,
> };

Does this implies clock rates should be set using clk_round_rate() and
not clk_set_rate() if I understand this right?

>
> (clk_rate_table_find() is called from sh_clk_div_set_rate())
>
> Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
> come from?
>

>From board initialization code, in order to provide a valid input
clock to OV7720 sensor.

The 10MHz seems like a workaround put in place to remove some
image quality issues, according to the comment:
https://elixir.free-electrons.com/linux/v4.15-rc9/source/arch/sh/boards/mach-migor/setup.c#L311

Thanks
   j

> > +
> > +   return pos - freq_table;
> > +   }
> >
> > return -ENOENT;
> >  }
>
> 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] sh: clk: Relax clk rate match test

[Geert Uytterhoeven]

Hi Jacopo,

CC linux-clk (yes I know this is about the legacy SH clock framework, but
the public API is/should be the same)

On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi
 wrote:
> When asking for a clk rate to be set, the sh core clock matches only
> exact rate values against the calculated frequency table entries. If the
> rate does not match exactly the test fails, and the whole frequency
> table is walked, resulting in selection of the last entry, corresponding to
> the lowest available clock rate.

IIUIC, the code does not select the last entry, but returns an error code,
which is propagated all the way up?

> Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" line),
> the calculated clock frequency 10088572 Hz gets ignored, and the clock is
> actually set to 5201920 Hz, which is the last available entry of the 
> frequencies
> table.

Perhaps 5201920 is just the default (or old value)?

> Relax the clock frequency match test, allowing selection of clock rates
> immediately slower than the required one.
>
> Signed-off-by: Jacopo Mondi 
>
> ---
> Hello renesas lists,
>
> I'm now working on handling frame rate for the ov7720 image sensor to have 
> that
> driver accepted as part of v4l2. The sensor is installed on on Migo-R board.
> In order to properly calculate pixel clock and the framerate I noticed the
> clock signal fed to the sensor from the SH7722 chip was always the lowest
> available one.
>
> This patch fixes the issues and allows me to properly select which clock
> frequency supply to the sensor, which according to datasheet does not support
> input clock frequencies slower than 10MHz (but works anyhow).
>
> As all patches for SH architecture I wonder where they should be picked up 
> from,
> as SH seems not maintained at the moment.
>
> Thanks
>j
>
> ---
>  drivers/sh/clk/core.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
> index 92863e3..d2cb94c 100644
> --- a/drivers/sh/clk/core.c
> +++ b/drivers/sh/clk/core.c
> @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
>  {
> struct cpufreq_frequency_table *pos;
>
> -   cpufreq_for_each_valid_entry(pos, freq_table)
> -   if (pos->frequency == rate)
> -   return pos - freq_table;
> +   cpufreq_for_each_valid_entry(pos, freq_table) {
> +   if (pos->frequency > rate)
> +   continue;

This assumes all frequency tables are sorted.

Shouldn't you pick the closest frequency?

However, that's what clk_rate_table_round() does, which is called from
sh_clk_div_round_rate(), and thus already used as .round_rate:

static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
.recalc = sh_clk_div_recalc,
.set_rate   = sh_clk_div_set_rate,
.round_rate = sh_clk_div_round_rate,
.enable = sh_clk_div_enable,
.disable= sh_clk_div_disable,
};

(clk_rate_table_find() is called from sh_clk_div_set_rate())

Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
come from?

> +
> +   return pos - freq_table;
> +   }
>
> return -ENOENT;
>  }

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 v2] v4l2-dev.h: fix symbol collision in media_entity_to_video_device()

[Sakari Ailus]

On Thu, Jan 25, 2018 at 02:08:52PM +0100, Niklas Söderlund wrote:
> A recent change to the media_entity_to_video_device() macro breaks some
> use-cases for the macro due to a symbol collision. Before the change
> this worked:
> 
> vdev = media_entity_to_video_device(link->sink->entity);
> 
> While after the change it results in a compiler error "error: 'struct
> video_device' has no member named 'link'; did you mean 'lock'?". While
> the following still works after the change.
> 
> struct media_entity *entity = link->sink->entity;
> vdev = media_entity_to_video_device(entity);
> 
> Fix the collision by renaming the macro argument to '__entity'.
> 
> Fixes: 69b925c5fc36d8f1 ("media: v4l2-dev.h: add kernel-doc to two macros")
> Signed-off-by: Niklas Söderlund 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH v2] v4l2-dev.h: fix symbol collision in media_entity_to_video_device()

[Niklas Söderlund]

A recent change to the media_entity_to_video_device() macro breaks some
use-cases for the macro due to a symbol collision. Before the change
this worked:

vdev = media_entity_to_video_device(link->sink->entity);

While after the change it results in a compiler error "error: 'struct
video_device' has no member named 'link'; did you mean 'lock'?". While
the following still works after the change.

struct media_entity *entity = link->sink->entity;
vdev = media_entity_to_video_device(entity);

Fix the collision by renaming the macro argument to '__entity'.

Fixes: 69b925c5fc36d8f1 ("media: v4l2-dev.h: add kernel-doc to two macros")
Signed-off-by: Niklas Söderlund 
---
 include/media/v4l2-dev.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

* Changes from v1
- Change argument name to '__entity' as suggested by Geert, Sakari and 
  Mauro.
- Added fixes tag.

diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 267fd2bed17bd3c1..322b8a9abb8dc45a 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -298,10 +298,10 @@ struct video_device
  * media_entity_to_video_device - Returns a  video_device from
  * the  media_entity embedded on it.
  *
- * @entity: pointer to  media_entity
+ * @__entity: pointer to  media_entity
  */
-#define media_entity_to_video_device(entity) \
-   container_of(entity, struct video_device, entity)
+#define media_entity_to_video_device(__entity) \
+   container_of(__entity, struct video_device, entity)
 
 /**
  * to_video_device - Returns a  video_device from the
-- 
2.15.1

[PATCH] sh: clk: Relax clk rate match test

[Jacopo Mondi]

When asking for a clk rate to be set, the sh core clock matches only
exact rate values against the calculated frequency table entries. If the
rate does not match exactly the test fails, and the whole frequency
table is walked, resulting in selection of the last entry, corresponding to
the lowest available clock rate.

Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" line),
the calculated clock frequency 10088572 Hz gets ignored, and the clock is
actually set to 5201920 Hz, which is the last available entry of the frequencies
table.

Relax the clock frequency match test, allowing selection of clock rates
immediately slower than the required one.

Signed-off-by: Jacopo Mondi 

---
Hello renesas lists,

I'm now working on handling frame rate for the ov7720 image sensor to have that
driver accepted as part of v4l2. The sensor is installed on on Migo-R board.
In order to properly calculate pixel clock and the framerate I noticed the
clock signal fed to the sensor from the SH7722 chip was always the lowest
available one.

This patch fixes the issues and allows me to properly select which clock
frequency supply to the sensor, which according to datasheet does not support
input clock frequencies slower than 10MHz (but works anyhow).

As all patches for SH architecture I wonder where they should be picked up from,
as SH seems not maintained at the moment.

Thanks
   j

---
 drivers/sh/clk/core.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
index 92863e3..d2cb94c 100644
--- a/drivers/sh/clk/core.c
+++ b/drivers/sh/clk/core.c
@@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
 {
struct cpufreq_frequency_table *pos;

-   cpufreq_for_each_valid_entry(pos, freq_table)
-   if (pos->frequency == rate)
-   return pos - freq_table;
+   cpufreq_for_each_valid_entry(pos, freq_table) {
+   if (pos->frequency > rate)
+   continue;
+
+   return pos - freq_table;
+   }

return -ENOENT;
 }
--
2.7.4

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

[Steven Rostedt]

On Wed, 24 Jan 2018 22:55:13 -0800
Frank Rowand  wrote:

> Hi Steve,

> 
> Off the top of your head, can you tell me know early in the boot
> process a trace_event can be called and successfully provide the
> data to someone trying to debug early boot issues?

The trace events are enabled by early_initcall().

> 
> Also, way back when version 1 of this patch was being discussed,
> a question about stacktrace triggers:
> 
>  >>> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
>  >>> # cat trace | grep -A6 "/pci@8002018"
>  >>
>  >> Just to let you know that there is now stacktrace event triggers, 
> where
>  >> you don't need to stacktrace all events, you can pick and choose. And
>  >> even filter the stack trace on specific fields of the event.
>  >
>  > This is great, and I did figure that out this afternoon. One thing I 
> was
>  > still trying to determine though was whether its possible to set these
>  > triggers at boot? As far as I could tell I'm still limited to
>  > "trace_options=stacktrace" as a kernel boot parameter to get the stack
>  > for event tracepoints.  
> 
>  No not yet. But I'll add that to the todo list.
> 
>  Thanks,
> 
>  -- Steve
> 
> Is this still on your todo list, or is it now available?

Still on the todo list. As someone once said, there really is no todo
list, but just work on the stuff that people are yelling the loudest
about. Yell louder, and it will get done quicker ;-)

-- Steve

Re: [PATCH/RFC 4/4] drm: rcar-du: Add support for color keying on Gen3

[Maxime Ripard]

Hi,

On Sun, Dec 17, 2017 at 02:17:24AM +0200, Laurent Pinchart wrote:
> +static const struct drm_prop_enum_list colorkey_modes[] = {
> + { 0, "disabled" },
> + { 1, "source" },
> +};
> +
>  int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>unsigned int crtcs)
>  {
> @@ -441,6 +453,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>  rcdu->props.alpha, 255);
>   drm_plane_create_zpos_property(>plane, 1, 1,
>  vsp->num_planes - 1);
> + drm_plane_create_colorkey_properties(>plane,
> +  colorkey_modes,
> +  ARRAY_SIZE(colorkey_modes),
> +  true);

You seem to define the same list in your enumeration between your
patch 2 and this one. Can this be something made generic too?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH/RFC 1/4] drm: Add colorkey properties

[Maxime Ripard]

On Sun, Dec 17, 2017 at 02:17:21AM +0200, Laurent Pinchart wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent, or gain a
> programmable alpha value.
> 
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds four properties
> related to color keying named colorkey.min, colorkey.max, colorkey.alpha
> and colorkey.mode. Additional properties can be defined by drivers to
> expose device-specific features.
> 
> Signed-off-by: Laurent Pinchart 

Sorry for the delay,
Reviewed-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

RE: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support

[Fabrizio Castro]

Thank you Marc.

Cheers,
Fabrizio

> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: 25 January 2018 08:53
> To: Fabrizio Castro 
> Cc: Simon Horman ; Geert Uytterhoeven 
> ; linux-...@vger.kernel.org;
> net...@vger.kernel.org; devicet...@vger.kernel.org; 
> linux-renesas-soc@vger.kernel.org; Chris Paterson
> ; Biju Das ; Wolfgang 
> Grandegger ; Rob Herring
> ; Mark Rutland 
> Subject: Re: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can 
> support
>
> On 01/24/2018 06:22 PM, Fabrizio Castro wrote:
> > thank you for Acking the patch, just wondering if this patch has any
> > chance to end up in v4.16?
>
> I can take this via the linux-can tree, if no one else takes it.
>
> Marc
>
> --
> Pengutronix e.K.  | Marc Kleine-Budde   |
> Industrial Linux Solutions| Phone: +49-231-2826-924 |
> Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH] v4l2-dev.h: fix symbol collision in media_entity_to_video_device()

[Mauro Carvalho Chehab]

Hi Niklas,

Em Thu, 25 Jan 2018 01:34:30 +0100
Niklas Söderlund  escreveu:

> A recent change to the media_entity_to_video_device() macro breaks some
> use-cases for the macro due to a symbol collision. Before the change
> this worked:
> 
> vdev = media_entity_to_video_device(link->sink->entity);
> 
> While after the change it results in a compiler error "error: 'struct
> video_device' has no member named 'link'; did you mean 'lock'?". While
> the following still works after the change.
> 
> struct media_entity *entity = link->sink->entity;
> vdev = media_entity_to_video_device(entity);
> 
> Fix the collision by renaming the macro argument to 'media_entity'.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  include/media/v4l2-dev.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Hi Mauro,
> 
> As the offending commit is not yet upstream and I'm not sure if the 
> commit ids in the media-tree are stable. If they are please attach the 
> following fixes tag.

They are. 

> 
> Fixes: 69b925c5fc36d8f1 ("media: v4l2-dev.h: add kernel-doc to two macros")
> 
> Regards,
> // Niklas
> 
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index 267fd2bed17bd3c1..f0fc1ebda47244b3 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -298,10 +298,10 @@ struct video_device
>   * media_entity_to_video_device - Returns a  video_device from
>   *   the  media_entity embedded on it.
>   *
> - * @entity: pointer to  media_entity
> + * @media_entity: pointer to  media_entity
>   */
> -#define media_entity_to_video_device(entity) \
> - container_of(entity, struct video_device, entity)
> +#define media_entity_to_video_device(media_entity) \
> + container_of(media_entity, struct video_device, entity)

Instead, the best would be to use __entity (or __media_entity).
That would very likely prevent future conflicts.

>  
>  /**
>   * to_video_device - Returns a  video_device from the




Cheers,
Mauro

Re: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support

[Marc Kleine-Budde]

On 01/24/2018 06:22 PM, Fabrizio Castro wrote:
> thank you for Acking the patch, just wondering if this patch has any
> chance to end up in v4.16?

I can take this via the linux-can tree, if no one else takes it.

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

[Daniel Lezcano]

On 25/01/2018 09:21, Geert Uytterhoeven wrote:
> Hi Daniel,
> 
> On Thu, Jan 25, 2018 at 9:09 AM, Daniel Lezcano
>  wrote:
>> On 24/01/2018 17:49, Fabrizio Castro wrote:
>>> I am sorry to bother you, just wondering if you think there are any chances 
>>> for this patch to applied on top of v4.16?
>>
>> You can take it through the renesas tree.
>>
>> Acked-by: Daniel Lezcano 
> 
> Thank you!
> 
> Unfortunately it's a bit late to get non-bugfixes in v4.16 through the renesas
> tree and arm-soc.

I thought they were going through the renesas tree, so I discarded them :/

May be Thomas can take them in the tip/timers tree ?

Thomas ?


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

[Frank Rowand]

On 01/21/18 06:31, Wolfram Sang wrote:
> From: Tyrel Datwyler 
> 
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
> 
> With the recent upstreaming of the refcount API several device_node
> underflows and leaks have come to my attention in the pseries (DLPAR)
> dynamic logical partitioning code (ie. POWER speak for hotplugging
> virtual and physcial resources at runtime such as cpus or IOAs). These
> tracepoints provide a easy and quick mechanism for validating the
> reference counting of device_nodes during their lifetime.
> 
> Further, when pseries lpars are migrated to a different machine we
> perform a live update of our device tree to bring it into alignment with
> the configuration of the new machine. The of_reconfig_notify trace point
> provides a mechanism that can be turned for debuging the device tree
> modifications with out having to build a custom kernel to get at the
> DEBUG code introduced by commit 00aa37206e1a54 ("of/reconfig: Add debug
> output for OF_RECONFIG notifiers").
> 
> The following trace events are provided: of_node_get, of_node_put,
> of_node_release, and of_reconfig_notify. These trace points require a
> kernel built with ftrace support to be enabled. In a typical environment
> where debugfs is mounted at /sys/kernel/debug the entire set of
> tracepoints can be set with the following:
> 
>   echo "of:*" > /sys/kernel/debug/tracing/set_event
> 
> or
> 
>   echo 1 > /sys/kernel/debug/tracing/events/of/enable
> 
> The following shows the trace point data from a DLPAR remove of a cpu
> from a pseries lpar:
> 
> cat /sys/kernel/debug/tracing/trace | grep "POWER8@10"
> 
> cpuhp/23-147   [023]    128.324827:
> of_node_put: refcount=5, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147   [023]    128.324829:
> of_node_put: refcount=4, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147   [023]    128.324829:
> of_node_put: refcount=3, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147   [023]    128.324831:
> of_node_put: refcount=2, dn->full_name=/cpus/PowerPC,POWER8@10
>drmgr-7284  [009]    128.439000:
> of_node_put: refcount=1, dn->full_name=/cpus/PowerPC,POWER8@10
>drmgr-7284  [009]    128.439002:
> of_reconfig_notify: action=DETACH_NODE, 
> dn->full_name=/cpus/PowerPC,POWER8@10,
> prop->name=null, old_prop->name=null
>drmgr-7284  [009]    128.439015:
> of_node_put: refcount=0, dn->full_name=/cpus/PowerPC,POWER8@10
>drmgr-7284  [009]    128.439016:
> of_node_release: dn->full_name=/cpus/PowerPC,POWER8@10, dn->_flags=4
> 
> Signed-off-by: Tyrel Datwyler 
> [wsa: fixed commit abbrev and one of the sysfs paths in commit desc,
> removed trailing space and fixed pointer declaration in code]
> Signed-off-by: Wolfram Sang 
> ---
>  drivers/of/dynamic.c  | 32 ++--
>  include/trace/events/of.h | 93 
> +++
>  2 files changed, 105 insertions(+), 20 deletions(-)
>  create mode 100644 include/trace/events/of.h
> 
> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> index ab988d88704da0..b0d6ab5a35b8c6 100644
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -21,6 +21,9 @@ static struct device_node *kobj_to_device_node(struct 
> kobject *kobj)
>   return container_of(kobj, struct device_node, kobj);
>  }
>  
> +#define CREATE_TRACE_POINTS
> +#include 
> +
>  /**
>   * of_node_get() - Increment refcount of a node
>   * @node:Node to inc refcount, NULL is supported to simplify writing of
> @@ -30,8 +33,10 @@ static struct device_node *kobj_to_device_node(struct 
> kobject *kobj)
>   */
>  struct device_node *of_node_get(struct device_node *node)
>  {
> - if (node)
> + if (node) {
>   kobject_get(>kobj);
> + trace_of_node_get(refcount_read(>kobj.kref.refcount), 
> node->full_name);
> + }
>   return node;
>  }
>  EXPORT_SYMBOL(of_node_get);
> @@ -43,8 +48,10 @@ EXPORT_SYMBOL(of_node_get);
>   */
>  void of_node_put(struct device_node *node)
>  {
> - if (node)
> + if (node) {
> + trace_of_node_put(refcount_read(>kobj.kref.refcount) - 1, 
> node->full_name);
>   kobject_put(>kobj);
> + }
>  }
>  EXPORT_SYMBOL(of_node_put);
>  
> @@ -75,24 +82,7 @@ const char *action_names[] = {
>  int of_reconfig_notify(unsigned long action, struct of_reconfig_data *p)
>  {
>   int rc;
> -#ifdef DEBUG
> - struct of_reconfig_data *pr = p;
> -
> - switch (action) {
> - case OF_RECONFIG_ATTACH_NODE:
> - case OF_RECONFIG_DETACH_NODE:
> - pr_debug("notify %-15s %pOF\n", action_names[action],
> - pr->dn);
> - break;
> - case 

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

[Frank Rowand]

On 01/25/18 00:01, Geert Uytterhoeven wrote:
> Hi Frank,
> 
> On Thu, Jan 25, 2018 at 7:48 AM, Frank Rowand  wrote:
>>>  create mode 100644 include/trace/events/of.h
>>
>> mode looks incorrect.  Existing files in include/trace/events/ are -rw-rw
> 
> Not in my git clone ;-) 644 should be fine.
> 
> Gr{oetje,eeting}s,
> 
> Geert

Thanks!!!  I just learned something new about git.  Now I have to go experiment
a bit to make sure I learned properly.

-Frank

Re: [PATCH v2 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

[Daniel Lezcano]

On 24/01/2018 17:49, Fabrizio Castro wrote:
> Hello Daniel,
> 
> I am sorry to bother you, just wondering if you think there are any chances 
> for this patch to applied on top of v4.16?

You can take it through the renesas tree.

Acked-by: Daniel Lezcano 


>> Subject: [PATCH v2 1/3] dt-bindings: timer: renesas, cmt: Document 
>> r8a774[35] CMT support
>>
>> Document SoC specific compatible strings for r8a7743 and r8a7745.
>> No driver change is needed as the fallback strings will activate
>> the right code.
>>
>> Signed-off-by: Fabrizio Castro 
>> Reviewed-by: Biju Das 
>> Reviewed-by: Geert Uytterhoeven 
>> Reviewed-by: Rob Herring 
>> Reviewed-by: Simon Horman 
>> ---
>> v1->v2:
>> * "R-Car Gen2 or RZ/G1." -> "R-Car Gen2 and RZ/G1."
>> * "all the R-Car" -> "R-Car"
>>
>>  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 14 ++
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
>> b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> index d740989..b40add2 100644
>> --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> @@ -22,6 +22,10 @@ Required Properties:
>>
>>  - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4.
>>  - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4.
>> +- "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743.
>> +- "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743.
>> +- "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745.
>> +- "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745.
>>  - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790.
>>  - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790.
>>  - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791.
>> @@ -31,10 +35,12 @@ Required Properties:
>>  - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794.
>>  - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794.
>>
>> -- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car 
>> Gen2.
>> -- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car 
>> Gen2.
>> -These are fallbacks for r8a73a4 and all the R-Car Gen2
>> -entrieslisted above.
>> +- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car 
>> Gen2
>> +and RZ/G1.
>> +- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car 
>> Gen2
>> +and RZ/G1.
>> +These are fallbacks for r8a73a4, R-Car Gen2 and RZ/G1 entries
>> +listed above.
>>
>>- reg: base address and length of the registers block for the timer 
>> module.
>>- interrupts: interrupt-specifier for the timer, one per channel.
>> --
>> 2.7.4
> 
> 
> 
> 
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
> Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
> No. 04586709.
> 


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

[Geert Uytterhoeven]

Hi Frank,

On Thu, Jan 25, 2018 at 7:48 AM, Frank Rowand  wrote:
>>  create mode 100644 include/trace/events/of.h
>
> mode looks incorrect.  Existing files in include/trace/events/ are -rw-rw

Not in my git clone ;-) 644 should be fine.

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] v4l2-dev.h: fix symbol collision in media_entity_to_video_device()

[Geert Uytterhoeven]

Hi Niklas,

On Thu, Jan 25, 2018 at 1:34 AM, Niklas Söderlund
 wrote:
> A recent change to the media_entity_to_video_device() macro breaks some
> use-cases for the macro due to a symbol collision. Before the change
> this worked:
>
> vdev = media_entity_to_video_device(link->sink->entity);
>
> While after the change it results in a compiler error "error: 'struct
> video_device' has no member named 'link'; did you mean 'lock'?". While
> the following still works after the change.
>
> struct media_entity *entity = link->sink->entity;
> vdev = media_entity_to_video_device(entity);
>
> Fix the collision by renaming the macro argument to 'media_entity'.

Thanks!
Given there also exists a "struct media_entity", using "_media_entity" seems
safe to me.

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