linux-kernel - Re: [PATCH] platform/chrome: lightbar: Assign drvdata during probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACK8Z6HFzn+tAL7KRmTF4Eet2VRYwr9D2sndeQXcfrQg2qkGPw@mail.gmail.com>
Date:   Thu, 27 Jun 2019 14:41:41 -0700
From:   Rajat Jain <rajatja@...gle.com>
To:     Enric Balletbo i Serra <enric.balletbo@...labora.com>
Cc:     Benson Leung <bleung@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Evan Green <evgreen@...gle.com>,
        Rajat Jain <rajatxjain@...il.com>
Subject: Re: [PATCH] platform/chrome: lightbar: Assign drvdata during probe

Hi Enric,

On Wed, Jun 26, 2019 at 1:34 PM Enric Balletbo i Serra
<enric.balletbo@...labora.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@...gle.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