On Tue, May 16, 2017 at 02:16:04PM +0200, Niklas Söderlund wrote: > Hi, > > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote: > > Hi Simon, > > > > On Tue, May 16, 2017 at 1:01 PM, Simon Horman <ho...@verge.net.au> wrote: > > > On Tue, May 16, 2017 at 11:07:34AM +0200, Geert Uytterhoeven wrote: > > >> On Tue, May 16, 2017 at 11:02 AM, Niklas Söderlund > > >> <niklas.soderl...@ragnatech.se> wrote: > > >> >> > Whit all this being said I still like to withdraw this patch as I > > >> >> > found > > >> >> > another fault with it, ravb_wol_restore() will unconditionally be > > >> >> > called > > >> >> > while ravb_wol_setup() will only be called if netif_running(ndev). > > >> >> > This > > >> >> > is en easy fix and I will send out a v2 once we figure out what to > > >> >> > do > > >> >> > about the clock. > > >> >> > > >> >> The clock issue is external to the ravb driver. If it works with > > >> >> s2idle, it should > > >> >> be OK. > > >> > > > >> > Do you think it's a good idea to move ahead with a v2 of the ravb WoL > > >> > patch to fix the unrelated issue and aim for it to be picked up prior > > >> > to > > >> > suspend/resume support is added to the CPG/MSSR? > > >> > > >> Sure. > > >> > > >> It can still be used on R-Car Gen2, where we're not s*d by mandatory > > >> PSCI. > > > > > > Is there some way for - e.g. the driver - to not enable WoL on Gen3 SoCs > > > until the clock issues is sorted out? I'm quite happy to enable features > > > > "priv->chip_id != RCAR_GEN3". However, as we don't have RAVB enabled > > on any R-Car Gen2 board, its use is limited. > > I agree that it's not so useful to enable this on Gen2 only.
Yeah, agreed. I had forgotten that RAVB only enabled on Gen3. ...
