Received-SPF: pass (google.com: domain of linux-kernel+bounces-56598-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240206-axi-spi-engine-round-2-1-v1-0-ea6eeb60f4fb@baylibre.com>
 <20240206-axi-spi-engine-round-2-1-v1-1-ea6eeb60f4fb@baylibre.com> <0158a82f-5445-43b9-9da5-8655c3a97c4d@wanadoo.fr>
In-Reply-To: <0158a82f-5445-43b9-9da5-8655c3a97c4d@wanadoo.fr>
From: David Lechner <dlechner@baylibre.com>
Date: Wed, 7 Feb 2024 08:09:46 -0600
Message-ID: <CAMknhBGGw41e8YfFfewgR=4zHr_BvfMxL3k4Ad2xbTLMEKTs7A@mail.gmail.com>
Subject: Re: [PATCH 1/2] spi: axi-spi-engine: remove use of ida for sync id
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: broonie@kernel.org, linux-kernel@vger.kernel.org, 
	linux-spi@vger.kernel.org, michael.hennerich@analog.com, nuno.sa@analog.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 6, 2024 at 3:50=E2=80=AFPM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> Le 06/02/2024 =C3=A0 21:31, David Lechner a =C3=A9crit :
> > Profiling has shown that ida_alloc_range() accounts for about 10% of th=
e
> > time spent in spi_sync() when using the AXI SPI Engine controller. This
> > call is used to create a unique id for each SPI message to match to an
> > IRQ when the message is complete.
> >
> > Since the core SPI code serializes messages in a message queue, we can
> > only have one message in flight at a time, namely host->cur_msg. This
> > means that we can use a fixed value instead of a unique id for each
> > message since there can never be more than one message pending at a
> > time.
> >
> > This patch removes the use of ida...
>
> So, maybe #include <linux/idr.h> can be removed as well?
> (untested)
>

Yes it should be removed.

>
>
> Also, even if unrelated to your changes, spi_engine_prepare_message()
> could use struct_size() in:
>
>         size =3D sizeof(*p->instructions) * (p_dry.length + 1);
>         p =3D kzalloc(sizeof(*p) + size, GFP_KERNEL);
>
> -->
>         p =3D kzalloc(struct_size(p, instructions, p_dry.length + 1, GFP_=
KERNEL);
>
> which can be a little safer and less verbose.

Thanks for the suggestion. I will consider it for a separate patch in
the future.