Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <501a8539-cfe1-3fd4-65db-fabf509cebc4@amd.com>
Date:   Wed, 29 Jun 2022 09:31:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH] gpio: gpio-xilinx: Check return value of
 of_property_read_u32
Content-Language: en-US
To:     Linus Walleij <linus.walleij@linaro.org>
CC:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Srinivas Neeli <srinivas.neeli@xilinx.com>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        "Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
        Michal Simek <michal.simek@xilinx.com>,
        <neelisrinivas18@gmail.com>,
        Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>,
        <srinivas.neeli@amd.com>, Srinivas Goud <sgoud@xilinx.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        git <git@xilinx.com>
References: <20220617051921.3801832-1-srinivas.neeli@xilinx.com>
 <CAHp75VfREw2F3bXDeS8O1jm0r1Ksj923jZDne9UE5vaHM+V17w@mail.gmail.com>
 <d780076d-ed24-f656-46b1-4d78cd0a17c1@amd.com>
 <CACRpkdbkm0C=GUvafi-ZzoqCk6k5fbNQ76GtvRtn_izcKWrVPA@mail.gmail.com>
From:   Michal Simek <michal.simek@amd.com>
In-Reply-To: <CACRpkdbkm0C=GUvafi-ZzoqCk6k5fbNQ76GtvRtn_izcKWrVPA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2022 07:31:40.0892
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bdb10e7-5491-4270-7d62-08da59a16857
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT020.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1201MB0049
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 6/28/22 14:27, Linus Walleij wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
> 
> 
> On Mon, Jun 20, 2022 at 8:26 AM Michal Simek <michal.simek@amd.com> wrote:
>> On 6/17/22 18:02, Andy Shevchenko wrote:
>>> On Fri, Jun 17, 2022 at 7:20 AM Srinivas Neeli
>>> <srinivas.neeli@xilinx.com> wrote:
>>>>
>>>> In five different instances the return value of "of_property_read_u32"
>>>> API was neither captured nor checked.
>>>>
>>>> Fixed it by capturing the return value and then checking for any error.
>>>>
>>>> Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com>
>>>> Addresses-Coverity: "check_return"
>>>
>>> I think the best course of action here is to go and fix Coverity while
>>> marking these as false positives.
>>>
>>> To the idea of castings -- this is not good style and (many?)
>>> maintainers in kernel do not accept such "workaround" for fixing
>>> broken tool.
>>
>> Let's wait for Linus what he will say about it.
>> I can't see nothing wrong about declaring that I am intentionally ignoring
>> return code.
> 
> I don't think this patch should be applied.
> 
> The problem with static analysis is that such tools have no feeling
> for context at all, and in this case the context makes it pretty
> clear why it is safe to ignore these return values.
> 
> But we need to adopt the tool to the code not adopt the code to
> the tool.

ok. No problem. Thanks for discussion.

Thanks,
Michal