Minor warning fixes #589

ChristosZosi · 2022-11-24T14:42:51Z

Description

While building the FreeRTOS-Plus-TCP library for the Xilinx UltraScale SoC, I came across some open warnings that would be triggered in particular cases.

Check the commit messages for more info about the warnings.

Test Steps

Compiler used to generate the warning in this PR:

arm-xilinx-eabi-gcc.exe (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiler options:

1: -pedantic -Wall -Wextra -O0
2: -pedantic -Wall -Wextra -O2

Related Issue

None

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The function pcGetPHIName(...) would be called only in the FreeRTOS_printf message, however FreeRTOS_printf maybe be defined to nothing e.g. release builds, which then the warning would come up

The calls to the function XEmacPs_SetHandler would trigger the pedantic warning: "ISO C forbids conversion of object pointer to function pointer type" The reason for this, is that the second parameter of the function XEmacPS_SetHandler is declared as pointer to a void type, but the function "expects" a function pointer, which in setup_isr rightly happens. However IMHO, this is just bad code from the side of Xilinx, as not on all architectures the size of a data pointer is identical to the size of a function pointer, which also is correctly recognised by the compiler. Instead of using the "bad" function XEmacPs_SetHandler, we can set the handlers manually to the EmacPS-instance.

ChristosZosi · 2022-11-24T16:44:29Z

/bot run uncrustify

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_physpeed.c

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c

paulbartell · 2022-11-25T18:35:51Z

@ChristosZosi : Thanks for the pull request. I added a few suggestions to your changes.

…hw.c Co-authored-by: Paul Bartell <paul.bartell@gmail.com>

Co-authored-by: Paul Bartell <paul.bartell@gmail.com>

ChristosZosi · 2022-11-28T07:18:50Z

There are still some warnings that I get when I try to build this port, however I was not sure how to resolve them. Maybe you could give me some suggestions:

Unused functions in x_emacpsif_physpeed.c
- static void ar8035Tick( XEmacPs * xemacpsp, uint32_t phy_addr ) seems to be not used anywhere
- static int prvAR803x_debug_reg_mask( XEmacPs * xemacpsp, uint32_t phy_addr, u16 reg, u16 clear, u16 set )
- static uint16_t prvAR803x_debug_reg_read( XEmacPs * xemacpsp, uint32_t phy_addr, u16 reg )

Can these functions be removed or what would be the alternative to "fix" the warnings?
Warning #warning the use of Jumbo Frames has not been tested sufficiently yet.

Can we remove these warnings? Or how one should test the Jumbo frame "sufficiently" enough, so that the warnings can be removed

paulbartell · 2022-11-28T22:19:09Z

Unused functions in x_emacpsif_physpeed.c

static void ar8035Tick( XEmacPs * xemacpsp, uint32_t phy_addr ) seems to be not used anywhere

static int prvAR803x_debug_reg_mask( XEmacPs * xemacpsp, uint32_t phy_addr, u16 reg, u16 clear, u16 set )

static uint16_t prvAR803x_debug_reg_read( XEmacPs * xemacpsp, uint32_t phy_addr, u16 reg )
Can these functions be removed or what would be the alternative to "fix" the warnings?

@AniruddhaKanhere and @htibosch Do you have a preference on this?

Warning #warning the use of Jumbo Frames has not been tested sufficiently yet.
Can we remove these warnings? Or how one should test the Jumbo frame "sufficiently" enough, so that the warnings can be removed

It sounds like you have validated Jumbo Frames, so the warning can probably be removed. @htibosch Do you have a particular set of tests in mind?

AniruddhaKanhere · 2022-12-05T05:23:58Z

There are still some warnings that I get when I try to build this port, however I was not sure how to resolve them. Maybe you could give me some suggestions:

Unused functions in x_emacpsif_physpeed.c

static void ar8035Tick( XEmacPs * xemacpsp, uint32_t phy_addr ) seems to be not used anywhere

static int prvAR803x_debug_reg_mask( XEmacPs * xemacpsp, uint32_t phy_addr, u16 reg, u16 clear, u16 set )

static uint16_t prvAR803x_debug_reg_read( XEmacPs * xemacpsp, uint32_t phy_addr, u16 reg )
Can these functions be removed or what would be the alternative to "fix" the warnings?

This file wasn't created by us and I would like to refrain from modifying it. It seems to me that this file is quite old and, thus maybe a bit outdated. If possible, we should replace it with a newer version of the file.

Warning #warning the use of Jumbo Frames has not been tested sufficiently yet.
Can we remove these warnings? Or how one should test the Jumbo frame "sufficiently" enough, so that the warnings can be removed

That was there to let the users know that the jumbo frame support is a new feature. And that they should use caution while using that as it might have some bugs. I agree that 'sufficiently' is not a measurable/quantifiable term, but it does convey the gist to the user :) .
Once we have tested Jumbo frame on Xilinx Ultrascale and have run various tests on it (such as sending many 'jumbo' packets, sending a packet bigger than jumbo frame, sending a mixture of both type of frames etc.), we shall remove that warning. But unless we are sure that it is safe to use and will not lead to some bad behavior of the code, I think we should leave that warning as is.

Does that seem apt @paulbartell and @htibosch?

htibosch

@ChristosZosi, I'm sorry to see that this PR lasts so long.

We are very busy with the IPv6/multi version of FreeRTOS+TCP.

About the warning and the Jumbo frames: I agree with what Aniruddha wrote about it. The stack has been written and tested with 1500-byte frames. I did a short test with Jumbo frames which went well. But I can't find the time yet to do extensive tests.

Ref FreeRTOS_Socket.c and FreeRTOS_ICMP.c : I hope that your changes will be preserved in the new stage if the library.

EDIT : forgot to tell that I tested the driver in real hardware, and it still worked well.

Here below two more remarks.
Thanks, Hein

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_physpeed.c

htibosch · 2022-12-28T08:39:44Z

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c

@@ -47,17 +47,16 @@ void setup_isr( xemacpsif_s * xemacpsif )
    /*
     * Setup callbacks
     */
-    XEmacPs_SetHandler( &xemacpsif->emacps, XEMACPS_HANDLER_DMASEND,
-                        ( void * ) emacps_send_handler,
-                        ( void * ) xemacpsif );


I missed this change: why would you remove the function calls and replace them with direct assignments?
Was there a problem with the functions? Or did it introduce a dependency on sources?

Hello @ChristosZosi,
I agree with Hein here. I am also not sure why was this removed?

In the commit message (9829705) I did add an explanation why the calls to the XEmacPs_SetHandler is problematic. In short, the compiler would output the pedantic warning ISO C forbids conversion of object pointer to function pointer type, when compiled with -Wpedantic.

The reason for it has to do with the function prototype of XEmacPs_SetHandler

LONG XEmacPs_SetHandler(XEmacPs *InstancePtr, u32 HandlerType, void *FuncPointer, void *CallBackRef);

Here you can see that the third parameter of the function is a void-pointer. However we pass to the function a function pointer. And here lies the issue, that function pointers (text) are not the same as void pointers (data). That is the reason for the compiler warning.

Here is also a nice discussion on stack overflow, which addresses this exact issue https://stackoverflow.com/questions/36645660/why-cant-i-cast-a-function-pointer-to-void

I hope this explains it 😄.

Thank you for the URL and for the insights.

Actually I had the same problem when using setsockopt() which has a parameter void *optval. It was not allowed to pass a function pointer.

As a solution, I introduced a struct called F_TCP_UDP_Handler_t that holds function pointers.
So let's go for your solution, assigning pointers directly.

AniruddhaKanhere

Thank you for being patient with us @ChristosZosi.
Can you please take a look at the comments and make the changes? I can make them on your behalf if you like.
Since this PR has been open for so long due to the (much appreciated) discussion, I will go ahead and make these changes if we do not hear from you soon.

Thanks,
Aniruddha

AniruddhaKanhere · 2022-12-29T18:07:59Z

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c

@@ -47,17 +47,16 @@ void setup_isr( xemacpsif_s * xemacpsif )
    /*
     * Setup callbacks
     */
-    XEmacPs_SetHandler( &xemacpsif->emacps, XEMACPS_HANDLER_DMASEND,
-                        ( void * ) emacps_send_handler,
-                        ( void * ) xemacpsif );


Hello @ChristosZosi,
I agree with Hein here. I am also not sure why was this removed?

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c

ChristosZosi · 2022-12-29T20:49:27Z

Hi @AniruddhaKanhere,

I did address all the open comments in the new commit (bd4c4e9). However I am currently on holidays and unfortunately I do not have a setup to test the new changes. Although these are insignificant changes, I would still suggest for them to be verified. I can do it also, but in two weeks.

Thank you

htibosch

Thank for these changes, I approve them.

htibosch · 2023-01-01T07:46:38Z

@AniruddhaKanhere wrote:

unfortunately I do not have a setup to test the new changes

Today I retested an Ultrascale project by running iperf3 on this board:

All went well, as expected.

* Eliminate compiler unused parameter warning * Eliminate compiler unused variable warnings * Eliminate compiler unused function warning The function pcGetPHIName(...) would be called only in the FreeRTOS_printf message, however FreeRTOS_printf maybe be defined to nothing e.g. release builds, which then the warning would come up * Rework callback setups in the EMAC-driver of the Xilinx UltraScale port The calls to the function XEmacPs_SetHandler would trigger the pedantic warning: "ISO C forbids conversion of object pointer to function pointer type" The reason for this, is that the second parameter of the function XEmacPS_SetHandler is declared as pointer to a void type, but the function "expects" a function pointer, which in setup_isr rightly happens. However IMHO, this is just bad code from the side of Xilinx, as not on all architectures the size of a data pointer is identical to the size of a function pointer, which also is correctly recognised by the compiler. Instead of using the "bad" function XEmacPs_SetHandler, we can set the handlers manually to the EmacPS-instance. * Uncrustify: triggered by comment. * Update source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c Co-authored-by: Paul Bartell <paul.bartell@gmail.com> * Apply suggestions from code review Co-authored-by: Paul Bartell <paul.bartell@gmail.com> * Address comments from reviews Co-authored-by: GitHub Action <action@github.com> Co-authored-by: Paul Bartell <paul.bartell@gmail.com>

@brief

* Update mainline to reflect changes after the release. (#563) * Update README.md * Update History.txt * Update version number macros * Update manifest.yml * IPv4/single SAME70 emac race condition (#567) * Implemented Maty's solution * Added a new statistic 'tx_write_fail' * Uncrustify: triggered by comment. Co-authored-by: Hein Tibosch <hein@htibosch.net> Co-authored-by: GitHub Action <action@github.com> * IPv4/Single: Add a SocketID to a socket (#546) * IPv4/Single: Add a SocketID to a socket * Change in comment * Applied uncrustify to format the source code * Added a few entries to lexicon.txt * Removed the 'ipconfigUSE_SetSocketID' option * Change to lexicon.txt * Add unit tests for the newly added API Co-authored-by: Hein Tibosch <hein@htibosch.net> Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com> Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com> * IPv4/single: SAME70 EMAC buffer sizes (#568) * Implemented Maty's solution * Added a new statistic 'tx_write_fail' * Uncrustify: triggered by comment. * Increase NETWORK_BUFFER_SIZE in order to include the 'ipBUFFER_PADDING' bytes * ICMP checksum calculated manually * Uncrustify: triggered by comment. * Update gmac_SAM.c Co-authored-by: Hein Tibosch <hein@htibosch.net> Co-authored-by: GitHub Action <action@github.com> Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com> * Eliminate some warnings (#578) * Eliminate some warnings related to print statements Authored-by: Pete Bone <pete-pjb@users.noreply.github.com > * Add MISRA justification for use of dynamic memory (#581) * Update deprecated macros in network driver files (#579) * Update deprecated macros in network driver files * Fix typo in RX driver. * Replace #warning with #error on test for deprecated macro. * Fix doxygen check Co-authored-by: PeterB <PeterB@PETE-LT.otg.local> Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com> * Fix Network-interface of the Xilinx UltraScale port (#588) The underlying issue was when the port would be used with Jumbo frames. During receives of Jumbo packets the data length was always set incorrectly, which then would cause buffer allocation issues and subsequently corrupted data would be sent to the IP-task. After some inspection in the Xilinx UltraScale port, I found out that when the data length would be set, the wrong mask from the Xilinx Ethernet MAC driver would be used. By using the right mask (XEMACPS_RXBUF_LEN_JUMBO_MASK) when Jumbo Frame support is enabled the issue was resolved * Fix Windows thread calling vTaskSuspendAll / xTaskResumeAll. (#592) Co-authored-by: Jason Carroll <czjaso@amazon.com> * Updated comments for FreeRTOS_select return value (#596) * Updated comments for FreeRTOS_select return value * Updated the function brief for FreeRTOS_select * Uncrustify: triggered by comment. * Updating FreeRTOS_select function @brief * Updated function brief for FreeRTOS_SignalSocket * Uncrustify: triggered by comment. * Update source/FreeRTOS_Sockets.c Co-authored-by: Ubuntu <ubuntu@ip-172-31-22-210.ec2.internal> Co-authored-by: GitHub Action <action@github.com> Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com> * Fixed readme script to build and run unit tests (#644) * Minor warning fixes (#589) * Eliminate compiler unused parameter warning * Eliminate compiler unused variable warnings * Eliminate compiler unused function warning The function pcGetPHIName(...) would be called only in the FreeRTOS_printf message, however FreeRTOS_printf maybe be defined to nothing e.g. release builds, which then the warning would come up * Rework callback setups in the EMAC-driver of the Xilinx UltraScale port The calls to the function XEmacPs_SetHandler would trigger the pedantic warning: "ISO C forbids conversion of object pointer to function pointer type" The reason for this, is that the second parameter of the function XEmacPS_SetHandler is declared as pointer to a void type, but the function "expects" a function pointer, which in setup_isr rightly happens. However IMHO, this is just bad code from the side of Xilinx, as not on all architectures the size of a data pointer is identical to the size of a function pointer, which also is correctly recognised by the compiler. Instead of using the "bad" function XEmacPs_SetHandler, we can set the handlers manually to the EmacPS-instance. * Uncrustify: triggered by comment. * Update source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c Co-authored-by: Paul Bartell <paul.bartell@gmail.com> * Apply suggestions from code review Co-authored-by: Paul Bartell <paul.bartell@gmail.com> * Address comments from reviews Co-authored-by: GitHub Action <action@github.com> Co-authored-by: Paul Bartell <paul.bartell@gmail.com> * Use CBMC XML output to enable VSCode debugger (#673) Prior to this commit, CBMC would emit logging information in plain text format, which does not contain information required for the CBMC VSCode debugger. This commit makes CBMC use XML instead of plain text. Co-authored-by: Mark Tuttle <tuttle@acm.org> * Remove need of token * Use vTaskDelay for sleep in the network-interface of xilinx_ultrascale (#698) The issue here is that, the FreeRTOS IP-task would block all other tasks during PHY-link speed negotiations, as it was using busy waiting. However this is not really ideal. A much more suitable function for such a task would be `vTaskDelay`. * Make sure that a TCP socket is closed only once (#707) * Make sure that a TCP socket is closed only once * Fix failing test cases for FreeRTOS_TCP_IP unit test modules post PR#705 changes * Uncrustify: triggered by comment. * Fix failing test cases for FreeRTOS_TCP_IP unit test modules post PR - 705 changes --------- Co-authored-by: Hein Tibosch <hein_tibosch@yahoo.es> Co-authored-by: GitHub Action <action@github.com> * Remove Dup function HAL_ETH_SetMDIOClockRange. (#711) * Update PR template to include checkbox for ut change (#734) * Main/TCP4 : ACK number in TCP RESET reply to SYN packet (#724) * Main/TCP4 : ACK number in TCP RESET reply to SYN packet * Typo fix * Add unit-test for coverage; Fix ntohl to htonl * Fix unit-test --------- Co-authored-by: Nikhil Kamath <110539926+amazonKamath@users.noreply.github.com> Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com> * #556 Initial Cmake Module definition. (#557) * #556 Initial Cmake Module definition. * Fixing CI builds, rely on pcap. (#556) * Updating tested configurations and minor clean-up of missing network interfaces (#555) * Further clean-up based on testing with build environment. (#555) * Using single definition for libraries everywhere. (#555) * Fixing A_CUSTOM_NETWORK_IF compile option. * Identifying and fixing compile issues. * Adding in additional warnings for GNU to ignore for now. * Fixing formatting issues with uncrustify. * More warnings for GNU used by CI/CD pipeline. * Assuming custom for build tests and using latest freertos-kernel code. Updated readme for how to consume at project level. * Fixing up issues identified in the PR. Making the build_test EXCLUDE_FROM_ALL so only compiled if requested. * Changing to support C89 instead of C99. Renaming tcp_tools to tcp_utilities to mimic the directory. * Using C90 ISO. Fixing compiler warnings. * Fixing non C90 compliant declaration after statement * Separating out CMakeLists so each port is independent. * Updating warning list in code. * Fixed formatting with uncrustify. * Fix failing tests * Fix failing unit-test * Fix a typo. --------- Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com> * CMake: Fix GIT_REPOSITORY and GIT_TAG (#742) * Allow use of loopback addresses in IP stack (127.0.0.0/8) (#754) Authored-by: Adam St. Amand <astamand@amazon.com> * Add release candidate automation (#761) This is a minimal subset of release automation which only creates a tag and verifies it. Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com> * Add CBMC-running GitHub Action; This commit adds a GitHub Action that runs the CBMC proofs in this repository upon pushes and pull requests * Copy CBMC output directory to CI location This commit ensures that the output directory for CBMC proofs is in the correct location expected by the FreeRTOS CI-CD repository. * rx: Read mac address using FreeRTOS_GetMACAddress() rather than using the defines (#765) * Read mac address using FreeRTOS_GetMACAddress() rather than using the defines --------- Co-authored-by: GitHub Action <action@github.com> * cmake: Remove add_subdirectory( cbmc ) call CBMC proofs cannot currently be run using CMake. fixes #753 * FreeRTOS_IP.h: Fix build error introduced by 55658e1 in FreeRTOS-Kernel * Add Nxp1060 network interface (#774) * Update PR template to include checkbox for ut change * Create NetworkInterface.c * Uncrustify: triggered by comment. * Address PR comments * Uncrustify: triggered by comment. * Update NetworkInterface.c * Uncrustify: triggered by comment. * Update copyright year * Refactor the init function. Add 'brief'. Cleanup. * Uncrustify: triggered by comment. * Update global link status only when the network is quiet * Uncrustify: triggered by comment. * Update copyright yeat * Update the driver to deal with network cable disconnects * Uncrustify: triggered by comment. * Update NetworkInterface.c * Clean up and address PR comments * More cleanup and address PR comments * Uncrustify: triggered by comment. * Empty-Commit * Address issue comments * Uncrustify: triggered by comment. * Empty-Commit to trigger workflow * Remove Full-Duplex restriction * Uncrustify: triggered by comment. * Empty-Commit to trigger workflow --------- Co-authored-by: GitHub Action <action@github.com> * Correct GCC warnings (#798) * Correct GCC warnings Corrects warnings with current GCC flags for GCC 7.5.0. The only suppressed warning pertains to function to object pointer conversion which is required and common for socket callbacks. * PR feedback --------- Co-authored-by: Ubuntu <ubuntu@ip-10-0-137-67.ec2.internal> Co-authored-by: Nikhil Kamath <110539926+amazonKamath@users.noreply.github.com> * Cleanup of NXP1060 network driver (#801) * Update PR template to include checkbox for ut change * Empty-Commit to trigger workflow * Fix issues pointed out in PR comments * Uncrustify: triggered by comment. * Empty-Commit to trigger workflow --------- Co-authored-by: GitHub Action <action@github.com> * Fix Clang warnings (#809) Corrects several warnings from Clang flags for Clang 13. Inspired by @phelter's bug report #558 * uncrustify yml fix (#815) * Add NetworkDown notification to NetworkInterface.c [PR: #671] (#812) * Add NetworkDown notification to EMAC task * Add NetworkDown notification to NetworkInterface.c * Uncrustify: triggered by comment. * Introduce ipconfigSUPPORT_NETWORK_DOWN_EVENT compile flag * Fix formatting * Uncrustify: triggered by comment. --------- Co-authored-by: Filip Oleszek <filip.oleszek@o2.pl> Co-authored-by: zipperowiec <35423392+zipperowiec@users.noreply.github.com> Co-authored-by: GitHub Action <action@github.com> * Uncrustify bot command fix (#816) * fix uncrustify run command * test uncrustify * Revert "test uncrustify" This reverts commit f660ab4. * Fix uncrustify bot command - disable install prompt (#819) * fix uncrustify run command * test uncrustify * Revert "test uncrustify" This reverts commit f660ab4. * removing apt-get prompt while installing git * Removing deprecated set-output command from uncrustify bot run yml (#820) * fix uncrustify run command * test uncrustify * Revert "test uncrustify" This reverts commit f660ab4. * removing apt-get prompt while installing git * removing the deprecated set-output command from uncrustify bot run yml, use latest git * IPv4/Single: Let send() stop blocking after a connection reset (#561) * IPv4/Single: Let send() stop after a protocol error * Remove token need * Repaired unit-testing * Added the cunftion test_FreeRTOS_send_DisconnectionOccursDuringWait() * Added a comment for unit-test function test_FreeRTOS_send_DisconnectionOccursDuringWait() * Added an item to lexicon.txt * Restored original tcp_utilities * Restored original tcp_utilities, once more --------- Co-authored-by: Hein Tibosch <hein@htibosch.net> Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com> Co-authored-by: Nikhil Kamath <110539926+amazonKamath@users.noreply.github.com> * Add logs to print random number generation failure (#908) Add logs to print random number generation failure for better debugging of issue. * Update usage of uint64_t according to C90 standard (#907) Co-authored-by: kar-rahul-aws <118818625+kar-rahul-aws@users.noreply.github.com> * Fix pragma pack in CCS compiler to push/pop (#906) `#pragma pack(1)` would make it so that all structs inserted after pack_struct_start.h was included for the TI arm compiler would be packed, leading to potential unaligned memory access error. Refer: https://www.ti.com/lit/ug/spnu151w/spnu151w.pdf SECTION 5.11.23 * Modified libslirp backend file to cover different libslirp library versions (#929) Authored-by: Xiaodong Li <xiaodonn@amazon.com> * Update according to devIntegration * Update links to point to main directory --------- Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com> Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com> Co-authored-by: Hein Tibosch <hein_tibosch@yahoo.es> Co-authored-by: Hein Tibosch <hein@htibosch.net> Co-authored-by: GitHub Action <action@github.com> Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com> Co-authored-by: Pete Bone <pete-pjb@users.noreply.github.com> Co-authored-by: PeterB <PeterB@PETE-LT.otg.local> Co-authored-by: ChristosZosi <76208460+ChristosZosi@users.noreply.github.com> Co-authored-by: jasonpcarroll <23126711+jasonpcarroll@users.noreply.github.com> Co-authored-by: Jason Carroll <czjaso@amazon.com> Co-authored-by: Tony Josi <117763118+tony-josi-aws@users.noreply.github.com> Co-authored-by: Ubuntu <ubuntu@ip-172-31-22-210.ec2.internal> Co-authored-by: Paul Bartell <paul.bartell@gmail.com> Co-authored-by: Kareem Khazem <karkhaz@amazon.com> Co-authored-by: Mark Tuttle <tuttle@acm.org> Co-authored-by: Tony Josi <tonyjosi@amazon.com> Co-authored-by: ActoryOu <jay2002824@gmail.com> Co-authored-by: Nikhil Kamath <110539926+amazonKamath@users.noreply.github.com> Co-authored-by: phelter <paulheltera@gmail.com> Co-authored-by: Adam St. Amand <adam.stamand@gmail.com> Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com> Co-authored-by: sayyadumar <sayyadumar@users.noreply.github.com> Co-authored-by: Paul Bartell <pbartell@amazon.com> Co-authored-by: Kody Stribrny <89810515+kstribrnAmzn@users.noreply.github.com> Co-authored-by: Ubuntu <ubuntu@ip-10-0-137-67.ec2.internal> Co-authored-by: Filip Oleszek <filip.oleszek@o2.pl> Co-authored-by: zipperowiec <35423392+zipperowiec@users.noreply.github.com> Co-authored-by: kar-rahul-aws <118818625+kar-rahul-aws@users.noreply.github.com> Co-authored-by: Rahul Arasikere <arasikere.rahul@gmail.com> Co-authored-by: Xiaodong Li <85011700+ChaiTowKway@users.noreply.github.com>

ChristosZosi added 4 commits November 24, 2022 14:50

Eliminate compiler unused parameter warning

6cfc758

Eliminate compiler unused variable warnings

43ab28b

Eliminate compiler unused function warning

5665b9d

The function pcGetPHIName(...) would be called only in the FreeRTOS_printf message, however FreeRTOS_printf maybe be defined to nothing e.g. release builds, which then the warning would come up

ChristosZosi requested a review from a team as a code owner November 24, 2022 14:42

Uncrustify: triggered by comment.

bf1b30b

paulbartell reviewed Nov 25, 2022

View reviewed changes

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c Outdated Show resolved Hide resolved

paulbartell reviewed Nov 25, 2022

View reviewed changes

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_physpeed.c Outdated Show resolved Hide resolved

paulbartell reviewed Nov 25, 2022

View reviewed changes

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_physpeed.c Outdated Show resolved Hide resolved

paulbartell reviewed Nov 25, 2022

View reviewed changes

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_physpeed.c Outdated Show resolved Hide resolved

paulbartell reviewed Nov 25, 2022

View reviewed changes

source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_hw.c Outdated Show resolved Hide resolved

ChristosZosi and others added 2 commits November 28, 2022 07:54

Update source/portable/NetworkInterface/xilinx_ultrascale/x_emacpsif_…

24d6a76

…hw.c Co-authored-by: Paul Bartell <paul.bartell@gmail.com>

Apply suggestions from code review

ba1f887

Co-authored-by: Paul Bartell <paul.bartell@gmail.com>

Merge branch 'FreeRTOS:main' into warnings

2a01c42

Merge branch 'main' into warnings

398ff8c

htibosch previously approved these changes Dec 28, 2022

View reviewed changes

AniruddhaKanhere requested changes Dec 29, 2022

View reviewed changes

ChristosZosi and others added 2 commits December 29, 2022 21:08

Merge branch 'main' into warnings

773596f

Address comments from reviews

bd4c4e9

ChristosZosi dismissed htibosch’s stale review via bd4c4e9 December 29, 2022 20:36

AniruddhaKanhere approved these changes Dec 30, 2022

View reviewed changes

htibosch approved these changes Dec 31, 2022

View reviewed changes

kstribrnAmzn approved these changes Jan 4, 2023

View reviewed changes

AniruddhaKanhere merged commit 1615f72 into FreeRTOS:main Jan 4, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Minor warning fixes #589

Minor warning fixes #589

ChristosZosi commented Nov 24, 2022

ChristosZosi commented Nov 24, 2022

paulbartell commented Nov 25, 2022

ChristosZosi commented Nov 28, 2022

paulbartell commented Nov 28, 2022 •

edited

Loading

AniruddhaKanhere commented Dec 5, 2022

htibosch left a comment •

edited

Loading

htibosch Dec 28, 2022

AniruddhaKanhere Dec 29, 2022

ChristosZosi Dec 29, 2022

htibosch Dec 31, 2022 •

edited

Loading

AniruddhaKanhere left a comment

AniruddhaKanhere Dec 29, 2022

ChristosZosi commented Dec 29, 2022

htibosch left a comment

htibosch commented Jan 1, 2023

Minor warning fixes #589

Minor warning fixes #589

Conversation

ChristosZosi commented Nov 24, 2022

Description

Test Steps

Related Issue

ChristosZosi commented Nov 24, 2022

paulbartell commented Nov 25, 2022

ChristosZosi commented Nov 28, 2022

paulbartell commented Nov 28, 2022 • edited Loading

AniruddhaKanhere commented Dec 5, 2022

htibosch left a comment • edited Loading

Choose a reason for hiding this comment

htibosch Dec 28, 2022

Choose a reason for hiding this comment

AniruddhaKanhere Dec 29, 2022

Choose a reason for hiding this comment

ChristosZosi Dec 29, 2022

Choose a reason for hiding this comment

htibosch Dec 31, 2022 • edited Loading

Choose a reason for hiding this comment

AniruddhaKanhere left a comment

Choose a reason for hiding this comment

AniruddhaKanhere Dec 29, 2022

Choose a reason for hiding this comment

ChristosZosi commented Dec 29, 2022

htibosch left a comment

Choose a reason for hiding this comment

htibosch commented Jan 1, 2023

paulbartell commented Nov 28, 2022 •

edited

Loading

htibosch left a comment •

edited

Loading

htibosch Dec 31, 2022 •

edited

Loading