linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <oss@buserror.net>
To: Christophe Leroy <christophe.leroy@c-s.fr>,
	Wang Wenhu <wenhu.wang@vivo.com>,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Cc: kernel@vivo.com, Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
Date: Wed, 15 Apr 2020 14:27:51 -0500	[thread overview]
Message-ID: <f2a1f91f92c0fe4bce46c28222dea355d96e2090.camel@buserror.net> (raw)
In-Reply-To: <37b6b890-e537-7424-6b26-04565681f40a@c-s.fr>

On Wed, 2020-04-15 at 18:52 +0200, Christophe Leroy wrote:
> 
> Le 15/04/2020 à 17:24, Wang Wenhu a écrit :
> > +
> > +		if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
> 
> I'd prefer
> 		if (uiomem - info->mem >= MAX_UIO_MAPS) {
> 
> > +			dev_warn(&pdev->dev, "more than %d uio-maps for
> > device.\n",
> > +				 MAX_UIO_MAPS);
> > +			break;
> > +		}
> > +	}
> > +
> > +	while (uiomem < &info->mem[MAX_UIO_MAPS]) {
> 
> I'd prefer
> 
> 	while (uiomem - info->mem < MAX_UIO_MAPS) {
> 

I wouldn't.  You're turning a simple comparison into a division and a
comparison (if the compiler doesn't optimize it back into the original form),
and making it less clear in the process.

Of course, working with array indices to begin with instead of incrementing a
pointer would be more idiomatic.

> > +		uiomem->size = 0;
> > +		++uiomem;
> > +	}
> > +
> > +	if (info->mem[0].size == 0) {
> 
> Is there any point in doing all the clearing loop above if it's to bail 
> out here ?
> 
> Wouldn't it be cleaner to do the test above the clearing loop, by just 
> checking whether uiomem is still equal to info->mem ?

There's no point doing the clearing at all, since the array was allocated with
kzalloc().

> > +		dev_err(&pdev->dev, "error no valid uio-map configured\n");
> > +		ret = -EINVAL;
> > +		goto err_info_free_internel;
> > +	}
> > +
> > +	info->version = "0.1.0";
> 
> Could you define some DRIVER_VERSION in the top of the file next to 
> DRIVER_NAME instead of hard coding in the middle on a function ?

That's what v1 had, and Greg KH said to remove it.  I'm guessing that he
thought it was the common-but-pointless practice of having the driver print a
version number that never gets updated, rather than something the UIO API
(unfortunately, compared to a feature query interface) expects.  That said,
I'm not sure what the value is of making it a macro since it should only be
used once, that use is self documenting, it isn't tunable, etc.  Though if
this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro
again, it should be UIO_VERSION, not DRIVER_VERSION).

Does this really need a three-part version scheme?  What's wrong with a
version of "1", to be changed to "2" in the hopefully-unlikely event that the
userspace API changes?  Assuming UIO is used for this at all, which doesn't
seem like a great fit to me.

-Scott



  reply	other threads:[~2020-04-15 19:30 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 12:33 [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-15 12:33 ` [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu
2020-04-16  0:58   ` kbuild test robot
2020-04-15 12:33 ` [PATCH 2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-15 12:33 ` [PATCH 3/5] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-15 12:33 ` [PATCH 4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-15 12:33 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu
2020-04-15 12:49   ` Greg KH
2020-04-15 14:07     ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram>On Wed, Apr 15, 2020 at 05:33:46AM -0700, Wang Wenhu wrote: Wang Wenhu
2020-04-15 15:24     ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-15 15:24       ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu
2020-04-15 16:26         ` Christophe Leroy
2020-04-15 16:29         ` Christophe Leroy
2020-04-15 18:53         ` Scott Wood
2020-04-16  4:11           ` Wang Wenhu
2020-04-15 15:24       ` [PATCH v2,2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-15 15:24       ` [PATCH v2,3/5] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-15 15:24       ` [PATCH v2,4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-15 15:24       ` [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu
2020-04-15 16:52         ` Christophe Leroy
2020-04-15 19:27           ` Scott Wood [this message]
2020-04-16  6:30             ` Greg KH
2020-04-16 19:36               ` Scott Wood
2020-04-16  5:22           ` Wang Wenhu
2020-04-16  6:02             ` Christophe Leroy
2020-04-15 19:26         ` Scott Wood
2020-04-16  6:30           ` Greg KH
2020-04-16 19:40             ` Scott Wood
2020-04-16  7:29       ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-16  7:29         ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-16  7:29         ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-16  7:29         ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-16  7:29         ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu
2020-04-16  7:41       ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-16  7:41         ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-16  7:41         ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-16  7:41         ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-16  7:41         ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu
2020-04-16  7:49       ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-16  7:49         ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-16  7:49         ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-16  7:49         ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-16  7:49         ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu
2020-04-16  9:29         ` Re:[PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 王文虎
2020-04-16 10:36           ` [PATCH " Christophe Leroy
2020-04-16 11:14             ` 王文虎

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=f2a1f91f92c0fe4bce46c28222dea355d96e2090.camel@buserror.net \
    --to=oss@buserror.net \
    --cc=christophe.leroy@c-s.fr \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel@vivo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=wenhu.wang@vivo.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;
as well as URLs for NNTP newsgroup(s).