Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190625205101.33032-1-rajatja@google.com> <a755588b-1062-7c4f-7c03-f35ca23f39a4@collabora.com>
In-Reply-To: <a755588b-1062-7c4f-7c03-f35ca23f39a4@collabora.com>
From:   Rajat Jain <rajatja@google.com>
Date:   Thu, 27 Jun 2019 14:41:41 -0700
Message-ID: <CACK8Z6HFzn+tAL7KRmTF4Eet2VRYwr9D2sndeQXcfrQg2qkGPw@mail.gmail.com>
Subject: Re: [PATCH] platform/chrome: lightbar: Assign drvdata during probe
To:     Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc:     Benson Leung <bleung@chromium.org>,
        Guenter Roeck <groeck@chromium.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Evan Green <evgreen@google.com>,
        Rajat Jain <rajatxjain@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Enric,

On Wed, Jun 26, 2019 at 1:34 PM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
>
> Hi Rajat,
>
> On 25/6/19 22:51, Rajat Jain wrote:
> > The lightbar driver never assigned the drvdata in probe method, and thus
> > causes a panic when it is accessed at the suspend time.
>
> Good catch, that's one of the problems I currently have with mainline on Samus.
> The other one, that I didn't find time to look at is, that for some reason, when
> I suspend the system reboots. Is suspend/resume working for you in current mainline?

I haven't tried current mainline yet. (I tried, but wasn't able to
build it like I used to. If you have a recipe, can you share and I can
give it a try).
I was seeing the same symptoms on my Hatch (using 4.19) before this
patch. I found this was the cause of the reboot, and is fixed now with
this patch. May be you can try on Samus with its fix?

>
> There is no drvdata because we don't really need extra private data for this
> driver, the ec_dev is directly the drvdata provided by device parent. I am
> wondering if you can just do
>
>    struct cros_ec_dev *ec_dev = to_cros_ec_dev(dev);
>
> in the suspend/resume calls like we do in the show/store calls or get the
> drvdata from its parent. I guess I prefer the first one.

The dev in suspend() callback points to "cros-ec-lightbar" device
instead of "cros-ec-dev", so we'd need to reach the parent. I'll send
a new patch in a moment.

Thanks,

Rajat


>
> >
>
> Would be nice have a fixes tag here.
>
> > Signed-off-by: Rajat Jain <rajatja@google.com>
> > ---
> >  drivers/platform/chrome/cros_ec_lightbar.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_lightbar.c b/drivers/platform/chrome/cros_ec_lightbar.c
> > index d30a6650b0b5..98e514fc5830 100644
> > --- a/drivers/platform/chrome/cros_ec_lightbar.c
> > +++ b/drivers/platform/chrome/cros_ec_lightbar.c
> > @@ -578,11 +578,14 @@ static int cros_ec_lightbar_probe(struct platform_device *pd)
> >
> >       ret = sysfs_create_group(&ec_dev->class_dev.kobj,
> >                                &cros_ec_lightbar_attr_group);
> > -     if (ret < 0)
> > +     if (ret < 0) {
> >               dev_err(dev, "failed to create %s attributes. err=%d\n",
> >                       cros_ec_lightbar_attr_group.name, ret);
> > +             return ret;
> > +     }
> >
> > -     return ret;
> > +     platform_set_drvdata(pd, ec_dev);
> > +     return 0;
> >  }
> >
> >  static int cros_ec_lightbar_remove(struct platform_device *pd)
> >
>
> Thanks,
> ~ Enric