Recently, gpib driver got out of staging area. There is still a bit of work that
can be done to improve it.

Return values for *allocate_private functions as well as calling code in
gpib driver are all over the place. Unify them by returning -errno if
something fails, zero otherwise. Use the returned value as early return
value in case of error.

Untouched gpib files already use the proposed convention.

Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@protonmail.com>

Dominik Karol Piątkowski (9):
  gpib: agilent_82350b: Unify *allocate_private
  gpib: cb7210: Unify *allocate_private
  gpib: cec: Unify *allocate_private
  gpib: gpio: Unify *allocate_private
  gpib: hp_82335: Unify *allocate_private
  gpib: hp_82341: Unify *allocate_private
  gpib: ines: Unify *allocate_private
  gpib: pc2: Unify *allocate_private
  gpib: tnt4882: Unify *allocate_private

 drivers/gpib/agilent_82350b/agilent_82350b.c |  5 +++--
 drivers/gpib/cb7210/cb7210.c                 |  6 ++++--
 drivers/gpib/cec/cec_gpib.c                  |  8 +++++---
 drivers/gpib/gpio/gpib_bitbang.c             |  9 +++++----
 drivers/gpib/hp_82335/hp82335.c              |  7 ++++---
 drivers/gpib/hp_82341/hp_82341.c             |  5 +++--
 drivers/gpib/ines/ines_gpib.c                |  8 +++++---
 drivers/gpib/pc2/pc2_gpib.c                  |  8 +++++---
 drivers/gpib/tnt4882/tnt4882_gpib.c          | 17 ++++++++++-------
 9 files changed, 44 insertions(+), 29 deletions(-)

-- 
2.43.0

On Tue, Jan 13, 2026 at 07:08:37PM +0000, Dominik Karol Piątkowski wrote:
> Recently, gpib driver got out of staging area. There is still a bit of work that
> can be done to improve it.
> 
> Return values for *allocate_private functions as well as calling code in
> gpib driver are all over the place. Unify them by returning -errno if
> something fails, zero otherwise. Use the returned value as early return
> value in case of error.
> 
> Untouched gpib files already use the proposed convention.
> 
> Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@protonmail.com>

I don't see the point of the allocate_private() functions.  Why not
just open code it?

regards,
dan carpenter

Hi Dan,


On Monday, January 19th, 2026 at 08:34, Dan Carpenter <dan.carpenter@linaro.org> wrote:

> 
> 
> On Tue, Jan 13, 2026 at 07:08:37PM +0000, Dominik Karol Piątkowski wrote:
> 
> > Recently, gpib driver got out of staging area. There is still a bit of work that
> > can be done to improve it.
> > 
> > Return values for *allocate_private functions as well as calling code in
> > gpib driver are all over the place. Unify them by returning -errno if
> > something fails, zero otherwise. Use the returned value as early return
> > value in case of error.
> > 
> > Untouched gpib files already use the proposed convention.
> > 
> > Signed-off-by: Dominik Karol Piątkowski dominik.karol.piatkowski@protonmail.com
> 
> 
> I don't see the point of the allocate_private() functions. Why not
> just open code it?

In most cases, *allocate_private() functions are used just once, in the
*attach() functions. The exception is tnt4882_gpib.c, that has 3 *attach()
functions, so it makes sense to keep it at least there. From what I noticed,
*allocate_private sometimes just allocates memory for private_data (for example,
in agilent_82350b.c), but sometimes it also does a bit of other stuff (like
initializing private_data mutexes in agilent_82357a.c).

And tnt4882_gpib.c falls into the "also does a bit of other stuff" category.

If I were to open code it, I would have to leave tnt4882_gpib.c as-is, drop the
`Unify *allocate_private usage` patches and introduce patches that move the
*allocate_private() to *attach() functions. I think v3 has a cleaner approach.

What do you think about that?

Thanks,
Dominik Karol

> 
> regards,
> dan carpenter