Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220121172431.6876-1-sbinding@opensource.cirrus.com>
 <20220121172431.6876-2-sbinding@opensource.cirrus.com> <c821953a-6572-d60d-6a00-fccd541268c5@redhat.com>
In-Reply-To: <c821953a-6572-d60d-6a00-fccd541268c5@redhat.com>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Tue, 1 Feb 2022 15:52:38 +0100
Message-ID: <CAJZ5v0jGqUvZS113VewgsGm8cMJc2B=M5KyqmOHTPNy+R8KeEQ@mail.gmail.com>
Subject: Re: [PATCH v6 1/9] spi: Make spi_alloc_device and spi_add_device
 public again
To:     Hans de Goede <hdegoede@redhat.com>
Cc:     Stefan Binding <sbinding@opensource.cirrus.com>,
        Mark Brown <broonie@kernel.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>, Mark Gross <markgross@kernel.org>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        <alsa-devel@alsa-project.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-spi <linux-spi@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>,
        patches@opensource.cirrus.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Feb 1, 2022 at 3:26 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 1/21/22 18:24, Stefan Binding wrote:
> > This functions were previously made private since they
> > were not used. However, these functions will be needed
> > again.
> >
> > Partial revert of commit da21fde0fdb3
> > ("spi: Make several public functions private to spi.c")
> >
> > Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
>
> Thanks, patch looks good to me:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>

The series also looks good to me from the ACPI side, so what tree
should it go into?

> > ---
> >  drivers/spi/spi.c       |  6 ++++--
> >  include/linux/spi/spi.h | 12 ++++++++++++
> >  2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> > index 4599b121d744..1eb84101c4ad 100644
> > --- a/drivers/spi/spi.c
> > +++ b/drivers/spi/spi.c
> > @@ -532,7 +532,7 @@ static DEFINE_MUTEX(board_lock);
> >   *
> >   * Return: a pointer to the new device, or NULL.
> >   */
> > -static struct spi_device *spi_alloc_device(struct spi_controller *ctlr)
> > +struct spi_device *spi_alloc_device(struct spi_controller *ctlr)
> >  {
> >       struct spi_device       *spi;
> >
> > @@ -557,6 +557,7 @@ static struct spi_device *spi_alloc_device(struct spi_controller *ctlr)
> >       device_initialize(&spi->dev);
> >       return spi;
> >  }
> > +EXPORT_SYMBOL_GPL(spi_alloc_device);
> >
> >  static void spi_dev_set_name(struct spi_device *spi)
> >  {
> > @@ -652,7 +653,7 @@ static int __spi_add_device(struct spi_device *spi)
> >   *
> >   * Return: 0 on success; negative errno on failure
> >   */
> > -static int spi_add_device(struct spi_device *spi)
> > +int spi_add_device(struct spi_device *spi)
> >  {
> >       struct spi_controller *ctlr = spi->controller;
> >       struct device *dev = ctlr->dev.parent;
> > @@ -673,6 +674,7 @@ static int spi_add_device(struct spi_device *spi)
> >       mutex_unlock(&ctlr->add_lock);
> >       return status;
> >  }
> > +EXPORT_SYMBOL_GPL(spi_add_device);
> >
> >  static int spi_add_device_locked(struct spi_device *spi)
> >  {
> > diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> > index 7ab3fed7b804..0346a3ff27fd 100644
> > --- a/include/linux/spi/spi.h
> > +++ b/include/linux/spi/spi.h
> > @@ -1452,7 +1452,19 @@ spi_register_board_info(struct spi_board_info const *info, unsigned n)
> >   * use spi_new_device() to describe each device.  You can also call
> >   * spi_unregister_device() to start making that device vanish, but
> >   * normally that would be handled by spi_unregister_controller().
> > + *
> > + * You can also use spi_alloc_device() and spi_add_device() to use a two
> > + * stage registration sequence for each spi_device. This gives the caller
> > + * some more control over the spi_device structure before it is registered,
> > + * but requires that caller to initialize fields that would otherwise
> > + * be defined using the board info.
> >   */
> > +extern struct spi_device *
> > +spi_alloc_device(struct spi_controller *ctlr);
> > +
> > +extern int
> > +spi_add_device(struct spi_device *spi);
> > +
> >  extern struct spi_device *
> >  spi_new_device(struct spi_controller *, struct spi_board_info *);
> >
> >
>