On 3/31/2018 6:04 PM, Alejandro Lucero wrote:
>
>
> On Fri, Mar 30, 2018 at 11:37 AM, Ferruh Yigit <ferruh.yi...@intel.com
> <mailto:ferruh.yi...@intel.com>> wrote:
>
> On 3/23/2018 5:35 PM, Alejandro Lucero wrote:
> > CPP refers to the internal NFP Command Push Pull bus. This patch allows
> > to create CPP commands from user space allowing to access any single
> > part of the chip.
> >
> > This CPP interface is the base for having other functionalities like
> > mutexes when accessing specific chip components, chip resources
> management,
> > firmware upload or using the NSP, an embedded arm processor which can
> > perform tasks on demand.
> >
> > NSP was the previous only way for doing things in the chip by the PMD,
> > where a NSPU interface was used for commands like firmware upload or
> > port link configuration. CPP interface supersedes NSPU, but it is still
> > possible to use NSP through CPP.
> >
> > CPP interface adds a great flexibility for doing things like extended
> > stats, firmware debugging or selecting properly the firmware file to
> > upload.
>
> It can be good to announce this new feature in release notes, what do you
> think?
>
>
> Uhmm, not sure about this. It is specific to the NFP PMD and I do not see it
> as
> a new feature, at least DPDK users will not be aware of it.
OK, if this internal and you think user won't be interested in this update.
>
>
>
> Also get some build errors [1], one is about zlib.h, normally we disable
> PMDs by
> default with external dependencies, is nfp depends to libz with this
> patch?
>
>
> I forgot to remove this reference. It is not needed now, but it was with the
> initial internal work.
>
> About the other build errors, I do not get them and I have used a couple of
> different systems, Ubuntu and Redhat. This is, of course, a serious concern.
> Can
> you give me more information about the system you are using?
>
> I remember I got some build error with other patches, from automatic builds
> made
> just after those patches were sent. I did not get any this time, just those
> warning for checkpatch which I was aware of. Is this automatic build not
> happening any more?
I will share more details. Automatic build still works and it has wider
coverage, this is from my local script...
>
>
>
> [1]
> ...dpdk/drivers/net/nfp/nfpcore/nfp_mutex.c:295:28: error: format
> specifies type
> 'short' but the argument has type 'unsigned int' [-Werror,-Wformat]
> printf("\tusage:%hd\n", mutex->usage);
>
> ~~~ ^~~~~~~~~~~~
>
>
> %u
>
> ...dpdk/drivers/net/nfp/nfpcore/nfp_cppcore.c:819:1: error: unused
> function
> '__nfp_bytemask_of' [-Werror,-Wunused-function]
> __nfp_bytemask_of(int width, uint64_t addr)
>
>
> ^
>
> ...dpdk/drivers/net/nfp/nfp_net.c:2971:35: error: format specifies type
> 'unsigned char' but the argument has type 'uint32_t' (aka 'unsigned int')
> [-Werror,-Wformat]
> cpp->serial[4], cpp->serial[5], cpp->interface >> 8,
>
>
> ^~~~~~~~~~~~~~~~~~~
> ...dpdk/drivers/net/nfp/nfp_net.c:2972:3: error: format specifies type
> 'unsigned
> char' but the argument has type 'unsigned int' [-Werror,-Wformat]
> cpp->interface & 0xff);
> ^~~~~~~~~~~~~~~~~~~~~
>
> ...dpdk/drivers/net/nfp/nfpcore/nfp_cppcore.c: In function
> ‘nfp_cpp_area_readl’:
> ...dpdk/drivers/net/nfp/nfpcore/nfp_cppcore.c:459:9: error: ‘tmp’ may be
> used
> uninitialized in this function [-Werror=maybe-uninitialized]
> *value = rte_le_to_cpu_32(tmp);
>
> ...dpdk/drivers/net/nfp/nfpcore/nfp_cppcore.c: In function
> ‘nfp_cpp_area_readq’:
> ...dpdk/drivers/net/nfp/nfpcore/nfp_cppcore.c:483:9: error: ‘tmp’ may be
> used
> uninitialized in this function [-Werror=maybe-uninitialized]
> *value = rte_le_to_cpu_64(tmp);
>
> ...dpdk/drivers/net/nfp/nfpcore/nfp_resource.c:34:10: fatal error:
> zlib.h: No
> such file or directory
> #include <zlib.h>
> ^~~~~~~~
>
> >
> > Signed-off-by: Alejandro Lucero <alejandro.luc...@netronome.com
> <mailto:alejandro.luc...@netronome.com>>
>
> <...>
>
> > diff --git a/drivers/net/nfp/nfpcore/nfp-common/nfp_cppat.h
> b/drivers/net/nfp/nfpcore/nfp-common/nfp_cppat.h
> > new file mode 100644
> > index 0000000..fbeec57
> > --- /dev/null
> > +++ b/drivers/net/nfp/nfpcore/nfp-common/nfp_cppat.h
> > @@ -0,0 +1,748 @@
> > +/*
> > + * Copyright (c) 2018 Netronome Systems, Inc.
> > + * All rights reserved.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> are
> met:
> > + *
> > + * 1. Redistributions of source code must retain the above copyright
> notice,
> > + * this list of conditions and the following disclaimer.
> > + *
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in the
> > + * documentation and/or other materials provided with the distribution
> > + *
> > + * 3. Neither the name of the copyright holder nor the names of its
> > + * contributors may be used to endorse or promote products derived
> from this
> > + * software without specific prior written permission.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> OF THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
>
> Can you please add new files with SPDX tags?
>
>
