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]
Message-ID: <f9b67b36-4b33-2557-0f0d-2819cc616cff@redhat.com>
Date:   Tue, 1 Feb 2022 15:54:25 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Stefan Binding <sbinding@...nsource.cirrus.com>,
        Mark Brown <broonie@...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

Hi,

On 2/1/22 15:52, Rafael J. Wysocki wrote:
> 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?

Minus the ALSA patch from 8/9 which should go through the sound
tree AFAIK, I would be happy to pick up the entire series in the
pdx86 tree.

This requires an ack from Mark though for me merging the spi bits,
Mark ?

Regards,

Hans


> 
>>> ---
>>>  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 *);
>>>
>>>
>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ