From: Jonathan Cameron <jic23@kernel.org>
To: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"Jonathan.Cameron@huawei.com" <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH] iio: Use an early return in iio_device_alloc to simplify code.
Date: Sat, 25 Apr 2020 16:47:13 +0100 [thread overview]
Message-ID: <20200425164713.201c89cc@archlinux> (raw)
In-Reply-To: <0aac8f5bd4836b8ac0013bf19b2d8a0f9a8b5c47.camel@analog.com>
On Mon, 20 Apr 2020 06:17:32 +0000
"Ardelean, Alexandru" <alexandru.Ardelean@analog.com> wrote:
> On Sun, 2020-04-19 at 16:13 +0100, jic23@kernel.org wrote:
> > [External]
> >
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Noticed whilst reviewing Alexandru's patch to the same function.
> > If we simply flip the logic and return NULL immediately after memory
> > allocation failure we reduce the indent of the following block and
> > end up with more 'idiomatic' kernel code.
> >
>
> I also was tempted to do it, but was tempted [a bit more] by the initial change
> that I goofed.
>
> A few thoughts on this [can be ignored].
> But, since doing this change, should 'dev' be renamed to 'indio_dev'?
> It shouldn't be a lot more code than the current change [I hope].
> When looking through IIO core, I got a minor/slight confusion on this alloc code
> about the name 'dev' [which is of type 'struct iio_dev' vs 'struct device', as
> is more customary].
>
> If 'dev' was chosen to fit within any 80 col-width limit, that limit should be
> less likely to hit now.
A different type of cleanup, so I think worth a separate patch
(even though it's messing with the same block of code.)
Got to keep to the rules I pester everyone else into following :)
So I'll apply this as is and might get the dev->indio_dev one out
after I've caught up with rest of email queue.
Thanks,
Jonathan
>
> 1 more inline.
>
> Well, even with/without these changes.
>
> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
>
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/iio/industrialio-core.c | 38 ++++++++++++++++-----------------
> > 1 file changed, 19 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > index f4daf19f2a3b..96f6dacb206d 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1504,27 +1504,27 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
> > alloc_size += IIO_ALIGN - 1;
> >
> > dev = kzalloc(alloc_size, GFP_KERNEL);
> > + if (!dev)
> > + return NULL;
> >
> > - if (dev) {
> > - dev->dev.groups = dev->groups;
> > - dev->dev.type = &iio_device_type;
> > - dev->dev.bus = &iio_bus_type;
> > - device_initialize(&dev->dev);
> > - dev_set_drvdata(&dev->dev, (void *)dev);
> > - mutex_init(&dev->mlock);
> > - mutex_init(&dev->info_exist_lock);
> > - INIT_LIST_HEAD(&dev->channel_attr_list);
> > -
> > - dev->id = ida_simple_get(&iio_ida, 0, 0, GFP_KERNEL);
> > - if (dev->id < 0) {
> > - /* cannot use a dev_err as the name isn't available */
> > - pr_err("failed to get device id\n");
> > - kfree(dev);
> > - return NULL;
> > - }
> > - dev_set_name(&dev->dev, "iio:device%d", dev->id);
> > - INIT_LIST_HEAD(&dev->buffer_list);
> > + dev->dev.groups = dev->groups;
> > + dev->dev.type = &iio_device_type;
> > + dev->dev.bus = &iio_bus_type;
> > + device_initialize(&dev->dev);
> > + dev_set_drvdata(&dev->dev, (void *)dev);
> > + mutex_init(&dev->mlock);
> > + mutex_init(&dev->info_exist_lock);
> > + INIT_LIST_HEAD(&dev->channel_attr_list);
> > +
> > + dev->id = ida_simple_get(&iio_ida, 0, 0, GFP_KERNEL);
> > + if (dev->id < 0) {
> > + /* cannot use a dev_err as the name isn't available */
> > + pr_err("failed to get device id\n");
> > + kfree(dev);
> > + return NULL;
>
> would it be too much for this patch to move this right after the kzalloc()?
> no strong opinion from my side to do it or not;
> but it does save some init cycles, and compresses this init block a bit;
It doesn't really save any cycles because the chance of failure of ID allocation
is negligible... Now I'd agree with you if writing from scratch, but as a
tidy up patch, it's good to keep things really simple.
>
> > }
> > + dev_set_name(&dev->dev, "iio:device%d", dev->id);
> > + INIT_LIST_HEAD(&dev->buffer_list);
> >
> > return dev;
> > }
next prev parent reply other threads:[~2020-04-25 15:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-19 15:13 [PATCH] iio: Use an early return in iio_device_alloc to simplify code jic23
2020-04-20 6:17 ` Ardelean, Alexandru
2020-04-25 15:47 ` Jonathan Cameron [this message]
2020-04-26 7:25 ` Ardelean, Alexandru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200425164713.201c89cc@archlinux \
--to=jic23@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=alexandru.Ardelean@analog.com \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.