linux-kernel - Re: [PATCH v6 1/9] spi: Make spi_alloc_device and spi_add

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 1 Feb 2022 15:52:38 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Stefan Binding <sbinding@...nsource.cirrus.com>,
        Mark Brown <broonie@...nel.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, Mark Gross <markgross@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        <alsa-devel@...a-project.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        patches@...nsource.cirrus.com
Subject: Re: [PATCH v6 1/9] spi: Make spi_alloc_device and spi_add_device
 public again

On Tue, Feb 1, 2022 at 3:26 PM Hans de Goede <hdegoede@...hat.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@...nsource.cirrus.com>
>
> Thanks, patch looks good to me:
>
> Reviewed-by: Hans de Goede <hdegoede@...hat.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 *);
> >
> >
>