public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox