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;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
To:     Julius Werner <jwerner@chromium.org>
From:   Stephen Boyd <swboyd@chromium.org>
In-Reply-To: <CAODwPW_sP2=w-qRmVTAm+HCgomxj7C1Z_tLtLzUy-eSp8QrZeA@mail.gmail.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Wei-Ning Huang <wnhuang@chromium.org>,
        Julius Werner <jwerner@chromium.org>,
        Brian Norris <briannorris@chromium.org>, samuel@sholland.org,
        Sudeep.Holla@arm.com
References: <20180808172414.29983-1-swboyd@chromium.org>
 <20180808172414.29983-3-swboyd@chromium.org>
 <CAODwPW_sP2=w-qRmVTAm+HCgomxj7C1Z_tLtLzUy-eSp8QrZeA@mail.gmail.com>
Message-ID: <153377174946.220756.11492509142148153962@swboyd.mtv.corp.google.com>
User-Agent: alot/0.7
Subject: Re: [PATCH v2 2/2] firmware: coreboot: Collapse platform drivers into bus
 core
Date:   Wed, 08 Aug 2018 16:42:29 -0700
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Quoting Julius Werner (2018-08-08 12:07:30)
> > +config GOOGLE_COREBOOT_TABLE_ACPI
> > +       tristate
> > +       default GOOGLE_COREBOOT_TABLE
> =

> I don't think this helps in upgrading (as your commit message says)
> unless you also keep the 'select GOOGLE_COREBOOT_TABLE' here, right?

Oh yes should be select, not default.

> =

> > -int coreboot_table_init(struct device *dev, void __iomem *ptr)
> > +static int coreboot_table_init(struct device *dev, void __iomem *ptr)
> =

> nit: There's little reason to keep coreboot_table_init() a separate
> function now. Could maybe compact the code a little more if you merge
> it into probe()? (Also could then do the signature sanity check before
> trusting the length values to map the whole thing, which is probably a
> good idea.)

Sure. I can make another patch for squashing that all together.

> =

> >         if (ptr_header) {
> >                 bus_unregister(&coreboot_bus_type);
> >                 iounmap(ptr_header);
> =

> Could ptr_header be handled by devm now, somehow?

Yes. It hasn't been devmified yet because that would be more things in
one big patch. This is quickly blowing up!

> Also, don't you have
> two bus_unregister() now (here and in coreboot_exit())? Or is that
> intentional?

That's nice. I didn't notice that module_init() was registering the bus
and then platform drivers could remove the bus later with the driver
unbind. I'll move them both into the driver bind/unbind path, in another
patch.

> =

> > +static struct platform_driver coreboot_table_driver =3D {
> > +       .probe =3D coreboot_table_probe,
> > +       .remove =3D coreboot_table_remove,
> > +       .driver =3D {
> > +               .name =3D "coreboot_table",
> > +               .acpi_match_table =3D ACPI_PTR(cros_coreboot_acpi_match=
),
> > +               .of_match_table =3D of_match_ptr(coreboot_of_match),
> =

> Who takes precedence if they both exist? Will we have two
> coreboot_table busses? (That would probably not be so good...)

I'm not aware of a system that has both ACPI and devicetree, so this
isn't a problem.