From: German Rivera <German.Rivera@freescale.com>
To: Kim Phillips <kim.phillips@freescale.com>,
Alexander Graf <agraf@suse.de>
Cc: "<gregkh@linuxfoundation.org>" <gregkh@linuxfoundation.org>,
"<arnd@arndb.de>" <arnd@arndb.de>,
"<linux-kernel@vger.kernel.org>" <linux-kernel@vger.kernel.org>,
"<stuart.yoder@freescale.com>" <stuart.yoder@freescale.com>,
"<scottwood@freescale.com>" <scottwood@freescale.com>,
"<linuxppc-release@linux.freescale.net>"
<linuxppc-release@linux.freescale.net>
Subject: Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs
Date: Thu, 18 Sep 2014 22:05:03 -0500 [thread overview]
Message-ID: <541B9D5F.20008@freescale.com> (raw)
In-Reply-To: <20140918152233.41647ee517393816bb35b72a@freescale.com>
On 09/18/2014 03:22 PM, Kim Phillips wrote:
> On Thu, 18 Sep 2014 15:14:03 +0200
>>> unnecessarily complicated error path, plus a simpler
>>>> implementation can be made if fn can return the mapped address, like
>>>> so:
>>>>
>>>> static void __iomem *map_mc_portal(phys_addr_t mc_portal_phys_addr,
>>>> uint32_t mc_portal_size)
>>>> {
>>>> struct resource *res;
>>>> void __iomem *mapped_addr;
>>>>
>>>> res = request_mem_region(mc_portal_phys_addr, mc_portal_size,
>>>> "mc_portal");
>>>> if (!res)
>>>> return NULL;
>>>>
>>>> mapped_addr = ioremap_nocache(mc_portal_phys_addr,
>>>> mc_portal_size);
>>>> if (!mapped_addr)
>>>> release_mem_region(mc_portal_phys_addr, mc_portal_size);
>>>>
>>>> return mapped_addr;
>>>> }
>>>>
>>>> the callsite can return -ENOMEM to its caller if returned NULL. This
>>>> can be improved even further if devm_ functions are used: this is
>>>> just an example of how to simplify the code using early returns
>>>> instead of goto error.
>>>
>>> I disagree. Having a common error return point is more maintainable than having multiple returns as having the clean-up logic in one place is more maintainable and makes the min path (non-error) more readable.
>
> my comment is not that much different from Joe's here:
>
> https://lkml.org/lkml/2014/9/17/381
>
> but hopefully all this will change with a devm_ based implementation.
>
I will refactor this function to use devm_ functions, to simplify the
error cleanup logic as you suggested, but still keep the current
signature of the function, as I don't think it is a good practice
to just return NULL in case of error, hiding the actual cause of the
error. Also, mixing returning a valid pointer and an error encoded
as an invalid pointer is not clean and can be error-prone for callers,
if some caller just checks for NULL instead of using IS_ERR() ir
IS_ERR_OR_NULL().
>>>>> +int __must_check fsl_create_mc_io(phys_addr_t mc_portal_phys_addr,
>>>>> + uint32_t mc_portal_size,
>>>>> + uint32_t flags, struct fsl_mc_io **new_mc_io)
>>>>> +{
>>>>> + int error = -EINVAL;
>>>>> + struct fsl_mc_io *mc_io = NULL;
>>>>> +
>>>>> + mc_io = kzalloc(sizeof(*mc_io), GFP_KERNEL);
>>>>> + if (mc_io == NULL) {
>>>>> + error = -ENOMEM;
>>>>> + pr_err("No memory to allocate mc_io\n");
>>>>> + goto error;
>>>>> + }
>>>>> +
>>>>> + mc_io->magic = FSL_MC_IO_MAGIC;
>>>>> + mc_io->flags = flags;
>>>>> + mc_io->portal_phys_addr = mc_portal_phys_addr;
>>>>> + mc_io->portal_size = mc_portal_size;
>>>>> + spin_lock_init(&mc_io->spinlock);
>>>>> + error = map_mc_portal(mc_portal_phys_addr,
>>>>> + mc_portal_size, &mc_io->portal_virt_addr);
>>>>> + if (error < 0)
>>>>> + goto error;
>>>>> +
>>>>> + *new_mc_io = mc_io;
>>>>> + return 0;
>>>>
>>>> if a fn only returns an address or error, it can return ERR_PTR
>>>> (e.g., -ENOMEM), and the callsite use IS_ERR() to determine whether
>>>> there was an error or address returned. This makes code much
>>>> simpler instead of passing address values back by reference.
>>> I disagree. I don't see why the alternative you suggest makes the code "much simpler".
>
> because it eliminates the need for the extra pass-by-reference
> argument struct fsl_mc_io **new_mc_io.
>
Having an extra pass-by-reference argument does not make the code
that complicated. Bit more importantly the simplicity that you gain
by not using the extra pass-by-reference pointer comes at the price
of making the interface less safer to use (more error-prone
for the caller as I mentioned above), which I think it is a bad trade off.
>>>>> +void fsl_destroy_mc_io(struct fsl_mc_io *mc_io)
>>>>> +{
>>>>> + if (WARN_ON(mc_io->magic != FSL_MC_IO_MAGIC))
>>>>> + return;
>>>>> +
>>>>> + if (mc_io->portal_virt_addr != NULL) {
>>>>> + unmap_mc_portal(mc_io->portal_phys_addr,
>>>>> + mc_io->portal_size, mc_io->portal_virt_addr);
>>>>
>>>> unmap_mc_portal already checks for virt_addr, this is another
>>>> example where the code goes too far checking for NULL.
>>> I disagree. Having the extra check is harmless and more importantly makes the intent explicit that we should only call unmap_mc_portal if we called map_mc_portal earlier.
>
> the code is doing this:
>
> if (mc_io->portal_virt_addr != NULL) {
> if (WARN_ON(mc_portal_virt_addr == NULL))
> return;
>
> which is redundant and therefore makes it unnecessarily complicated,
> after all, a stack trace will occur if mc_portal_virt_addr is
> referenced anyway, making the WARN_ON clause redundant, too.
>
All this will be gone with the refactoring to use devm_ APIs.
>>>>> + mc_io->portal_virt_addr = NULL;
>>>>> + }
>>>>> +
>>>>> + mc_io->magic = 0x0;
>>>>> + kfree(mc_io);
>>>>> +}
>
> btw, what's the point of zeroing out things that are being freed?
>
In this particular case, this comment doe snot apply anymore, as
the magic filed will be removed.
>>>>> +/**
>>>>> + * @brief Management Complex firmware version information
>>>>> + */
>>>>> +#define MC_VER_MAJOR 2
>>>>> +#define MC_VER_MINOR 0
>>>>
>>>> code should be adjusted to run on all *compatible* versions of h/w,
>>>> not strictly the one set in these defines.
>>> This comment is not precise enough be actionable.
>>> What exactly you want to be changed here?
>>
>> I think the easy thing to do is to convert the exact version check into a ranged version check: have minimum and maximum versions you support. Or a list of exact versions you support. Or not check for the version at all - or only for the major version and guarantee that the major version indicates backwards compatibility.
>
> yes, this was my point: elsewhere I noticed the code denies to run
> iff those defines are not matched exactly: that code should change
> to run as Alex describes.
>
As I mentioned in the reply to Alex, I will remove the minor version check.
next prev parent reply other threads:[~2014-09-19 3:05 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 17:34 [PATCH 0/4] drivers/bus: Freescale Management Complex bus driver patch series J. German Rivera
2014-09-11 17:34 ` [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs J. German Rivera
2014-09-11 18:45 ` Joe Perches
2014-09-17 16:35 ` German Rivera
2014-09-15 23:44 ` Kim Phillips
2014-09-16 4:31 ` Scott Wood
2014-09-16 19:28 ` Kim Phillips
2014-09-16 19:58 ` Scott Wood
2014-09-18 4:17 ` German Rivera
2014-09-18 13:14 ` Alexander Graf
2014-09-18 20:22 ` Kim Phillips
2014-09-18 23:03 ` Scott Wood
2014-09-18 23:13 ` Stuart Yoder
2014-09-18 23:29 ` Scott Wood
2014-09-18 23:46 ` Stuart Yoder
2014-09-19 3:05 ` German Rivera [this message]
2014-09-19 17:19 ` Kim Phillips
2014-09-19 19:06 ` Stuart Yoder
2014-09-19 20:24 ` Kim Phillips
2014-09-19 20:32 ` Alexander Graf
2014-09-19 20:41 ` Scott Wood
2014-09-19 21:46 ` Alexander Graf
2014-09-20 15:36 ` Stuart Yoder
2014-09-19 21:37 ` Stuart Yoder
2014-09-19 21:30 ` Stuart Yoder
2014-09-19 0:18 ` Stuart Yoder
2014-09-19 2:34 ` German Rivera
2014-09-19 18:25 ` Stuart Yoder
2014-09-19 20:58 ` Kim Phillips
2014-09-22 14:42 ` Stuart Yoder
2014-09-22 14:57 ` <gregkh@linuxfoundation.org>
2014-09-22 15:01 ` Stuart Yoder
2014-09-18 23:39 ` Stuart Yoder
2014-09-18 23:53 ` Scott Wood
2014-09-11 17:34 ` [PATCH 2/4] drivers/bus: Freescale Management Complex (fsl-mc) bus driver J. German Rivera
2014-09-11 18:49 ` Joe Perches
2014-09-17 23:50 ` German Rivera
2014-09-11 17:34 ` [PATCH 3/4] drivers/bus: Device driver for FSL-MC DPRC devices J. German Rivera
2014-09-11 17:34 ` [PATCH 4/4] Update MAINTAINERS file J. German Rivera
2014-09-15 23:44 ` [PATCH 0/4] drivers/bus: Freescale Management Complex bus driver patch series Kim Phillips
2014-09-18 0:20 ` German Rivera
2014-09-18 12:58 ` Alexander Graf
2014-09-19 0:31 ` German Rivera
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=541B9D5F.20008@freescale.com \
--to=german.rivera@freescale.com \
--cc=agraf@suse.de \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=kim.phillips@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-release@linux.freescale.net \
--cc=scottwood@freescale.com \
--cc=stuart.yoder@freescale.com \
/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.