Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1264843 > unrolled thread

Re: [PATCH 3/4] nvdimm: Add IOCTL pass thru

Started byDmitry Krivenok <krivenok.dmitry@gmail.com>
First post2015-11-07 15:10 +0100
Last post2015-11-12 16:40 +0100
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

Contents

  Re: [PATCH 3/4] nvdimm: Add IOCTL pass thru Dmitry Krivenok <krivenok.dmitry@gmail.com> - 2015-11-07 15:10 +0100
    Re: [PATCH 3/4] nvdimm: Add IOCTL pass thru Jerry Hoemann <jerry.hoemann@hpe.com> - 2015-11-09 23:00 +0100
      Re: [PATCH 3/4] nvdimm: Add IOCTL pass thru Dmitry Krivenok <krivenok.dmitry@gmail.com> - 2015-11-10 16:10 +0100
        Re: [PATCH 3/4] nvdimm: Add IOCTL pass thru Jerry Hoemann <jerry.hoemann@hpe.com> - 2015-11-11 22:50 +0100
          Re: [PATCH 3/4] nvdimm: Add IOCTL pass thru Dmitry Krivenok <krivenok.dmitry@gmail.com> - 2015-11-11 23:00 +0100
            Re: [PATCH 3/4] nvdimm: Add IOCTL pass thru Jerry Hoemann <jerry.hoemann@hpe.com> - 2015-11-12 16:40 +0100

#1264843 — Re: [PATCH 3/4] nvdimm: Add IOCTL pass thru

FromDmitry Krivenok <krivenok.dmitry@gmail.com>
Date2015-11-07 15:10 +0100
SubjectRe: [PATCH 3/4] nvdimm: Add IOCTL pass thru
Message-ID<qsclQ-3jn-7@gated-at.bofh.it>
> +       if (IS_ENABLED(CONFIG_ACPI_NFIT_DEBUG)) {
> +               dev_dbg(dev, "%s:%s cmd: %d input length: %d\n", __func__,
> +                               dimm_name, cmd, in_buf.buffer.length);
> +               print_hex_dump_debug("cmd: ", DUMP_PREFIX_OFFSET, 4,
> +                               4, in_buf.buffer.pointer, min_t(u32, 128,
> +                                       in_buf.buffer.length), true);
> +       }

Maybe move this code to a helper function? There are 4 almost
identical blocks now in acpi_nfit_ctl_passthru and
acpi_nfit_ctl_intel.

> +       for (i = 0; i < ARRAY_SIZE(pkg.h.res); i++)
> +               if (pkg.h.res[i])
> +                       return -EINVAL;

I'd rename "res" to "reserved" for clarity.

> +       /* This may be bigger that the fixed portion of the pakcage */

s/that/than/
s/pakcage/package/

> +               switch (type) {
> +               case NVDIMM_TYPE_INTEL:
> +                       rc = __nd_ioctl(nvdimm_bus, nvdimm, ro, cmd, arg);
> +                       break;
> +               case NVDIMM_TYPE_PASSTHRU:
> +                       rc = __nd_ioctl_passthru(nvdimm_bus, nvdimm, ro, cmd, arg);
> +                       break;
> +               default:
> +                       rc = -ENOTTY;
> +               }

The same comment. Identical code in nd_ioctl and nvdimm_ioctl.
Perhaps move to a helper function?

Thanks,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1266050

FromJerry Hoemann <jerry.hoemann@hpe.com>
Date2015-11-09 23:00 +0100
Message-ID<qt2DN-3TR-19@gated-at.bofh.it>
In reply to#1264843
Dmitry,

thanks for you review.  Questions in-line.


On Sat, Nov 07, 2015 at 05:02:36PM +0300, Dmitry Krivenok wrote:
> > +       if (IS_ENABLED(CONFIG_ACPI_NFIT_DEBUG)) {
> > +               dev_dbg(dev, "%s:%s cmd: %d input length: %d\n", __func__,
> > +                               dimm_name, cmd, in_buf.buffer.length);
> > +               print_hex_dump_debug("cmd: ", DUMP_PREFIX_OFFSET, 4,
> > +                               4, in_buf.buffer.pointer, min_t(u32, 128,
> > +                                       in_buf.buffer.length), true);
> > +       }
> 
> Maybe move this code to a helper function? There are 4 almost
> identical blocks now in acpi_nfit_ctl_passthru and
> acpi_nfit_ctl_intel.


Is your concern readibility or size of generated code (or both?)

I'll look to consolidating the debug printing in next version as additional patch.

> 
> > +       for (i = 0; i < ARRAY_SIZE(pkg.h.res); i++)
> > +               if (pkg.h.res[i])
> > +                       return -EINVAL;
> 
> I'd rename "res" to "reserved" for clarity.


Will do.



> 
> > +       /* This may be bigger that the fixed portion of the pakcage */
> 
> s/that/than/
> s/pakcage/package/


Will do.


> 
> > +               switch (type) {
> > +               case NVDIMM_TYPE_INTEL:
> > +                       rc = __nd_ioctl(nvdimm_bus, nvdimm, ro, cmd, arg);
> > +                       break;
> > +               case NVDIMM_TYPE_PASSTHRU:
> > +                       rc = __nd_ioctl_passthru(nvdimm_bus, nvdimm, ro, cmd, arg);
> > +                       break;
> > +               default:
> > +                       rc = -ENOTTY;
> > +               }
> 
> The same comment. Identical code in nd_ioctl and nvdimm_ioctl.
> Perhaps move to a helper function?


If we had a longer list, I would definitely say yes.  Not so sure with
just two types.  I'll take a look for the next version.


-- 

-----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer      Hewlett-Packard Enterprise

3404 E Harmony Rd. MS 36                        phone:  (970) 898-1022
Ft. Collins, CO 80528                           FAX:    (970) 898-0707
                                                email:  jerry.hoemann@hpe.com
-----------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1266565

FromDmitry Krivenok <krivenok.dmitry@gmail.com>
Date2015-11-10 16:10 +0100
Message-ID<qtiIy-6FU-9@gated-at.bofh.it>
In reply to#1266050
> Is your concern readibility or size of generated code (or both?)
>
> I'll look to consolidating the debug printing in next version as additional patch.

Just a minor style comment, not critical.

> If we had a longer list, I would definitely say yes.  Not so sure with
> just two types.  I'll take a look for the next version.

The same, just a style comment.

>   list_for_each_entry(nvdimm_bus, &nvdimm_bus_list, list) {
> - if (nvdimm_bus->id == id) {
> + if (nvdimm_bus->id != id)

I noticed another minor issue. You have switched from "==" to "!="
here, but you didn't add "break" after ioctl is handled for the found
bus.

Thanks,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1267460

FromJerry Hoemann <jerry.hoemann@hpe.com>
Date2015-11-11 22:50 +0100
Message-ID<qtLrc-8iQ-5@gated-at.bofh.it>
In reply to#1266565
On Tue, Nov 10, 2015 at 06:05:15PM +0300, Dmitry Krivenok wrote:
> 
> >   list_for_each_entry(nvdimm_bus, &nvdimm_bus_list, list) {
> > - if (nvdimm_bus->id == id) {
> > + if (nvdimm_bus->id != id)
> 
> I noticed another minor issue. You have switched from "==" to "!="
> here, but you didn't add "break" after ioctl is handled for the found
> bus.
> 

I added the continue.

the code is going through a list and wants to only do action when it
matches on id.  but, we still want to go through entire list.

-- 

-----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer      Hewlett-Packard Enterprise
-----------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1267465

FromDmitry Krivenok <krivenok.dmitry@gmail.com>
Date2015-11-11 23:00 +0100
Message-ID<qtLAR-8mQ-1@gated-at.bofh.it>
In reply to#1267460
> but, we still want to go through entire list.

Shouldn't you break the loop immediately after you found the bus and sent ioctl?
Maybe I'm missing something, but I see no reason to continue iterating
after the bus was found (even though you don't do anything and just
compare IDs and "continue").
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1268036

FromJerry Hoemann <jerry.hoemann@hpe.com>
Date2015-11-12 16:40 +0100
Message-ID<qu28G-2eq-43@gated-at.bofh.it>
In reply to#1267465
On Thu, Nov 12, 2015 at 12:52:47AM +0300, Dmitry Krivenok wrote:
> > but, we still want to go through entire list.
> 
> Shouldn't you break the loop immediately after you found the bus and sent ioctl?
> Maybe I'm missing something, but I see no reason to continue iterating
> after the bus was found (even though you don't do anything and just
> compare IDs and "continue").

okay, i understand now what you're saying.  i'll address in version 2.

-- 

-----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer      Hewlett-Packard Enterprise
-----------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web