From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B06DFC433F5 for ; Mon, 3 Jan 2022 01:26:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231308AbiACB0V (ORCPT ); Sun, 2 Jan 2022 20:26:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230110AbiACB0U (ORCPT ); Sun, 2 Jan 2022 20:26:20 -0500 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30BC3C061761; Sun, 2 Jan 2022 17:26:20 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id x7so72091430lfu.8; Sun, 02 Jan 2022 17:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LOG+LRnFpNPHGcbZgexu8NnNf42wYWPGSEjdgT8j34Y=; b=LDuf7jp1iGCDGF/Phth7mxhqpRpg6gEA869QeS6uWzxl7NG5QOemxoHXNMjYvowX1I MmOlEwTe46SDzM2b8blgf6TFvb9IV14yOW23g4r1ZG4h/WNl25rAggVGIHNa/GjwKj3s dBDEyAYkBUsY5J/87asojbXG+B5Ypa8BE/vLL0z0xtyAJ2SGWDtnq4q1p+0XzC7lhJ52 75aaf0dMceQClHkqHB9lDV2cqHZGVnRnbVrmM049bKvYznmK6Ps54XaXRUi3/NpfLbO2 hjCohLxihMTAfPLPIEnE5ka6I857i8Ry5KUe7P5dQT9EqHGvndZ7evUfLb6pj6f7pvrW EOnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LOG+LRnFpNPHGcbZgexu8NnNf42wYWPGSEjdgT8j34Y=; b=2CVnR/P6eD7TUTLWfj1II7JVMoijQc7R5BBXNFsgwixFEoiwYqBrVJhaEEnXorealH IkZ0rJdVzS3JyMLwDWDiE9EdNcKXOWrb5H24BBFZFPjcTa+YVznQVOq7csGk7//oh3s5 UHaYslIrB/yjTb8FmFKKXcSo0NL7t2vu10x5Rip1i0MJvtuKasu6YUeG5hYUZ/LQYkJF yYxfuR0XyA8mn2ttLV0QFl99yFh/CP7DR9DL8+tOMOsS0lwlutdng9P8rQUaaIYOjwXu YnQKm91YqsW1aMLW2m/251B85HHOOY8XCzwB7+/OGqqBrpfAynHItDxmufAtjfjJ+5KD qwWA== X-Gm-Message-State: AOAM532N54gFhOE8eG+ZYD2qmfKAb1oFCeRbb6T/fCLMq0qPEdfunLCh XeSzMLj2JNPHpLX+K0qfTag= X-Google-Smtp-Source: ABdhPJyEa/GRkFoaZ/6C94axN4nLg9bDFQsbmGsslW3JBM0Y64w0IUKXjq3OOgLvP86NJtfc2P1zyw== X-Received: by 2002:a05:6512:2305:: with SMTP id o5mr39533999lfu.564.1641173178486; Sun, 02 Jan 2022 17:26:18 -0800 (PST) Received: from [192.168.2.145] (46-138-43-24.dynamic.spd-mgts.ru. [46.138.43.24]) by smtp.googlemail.com with ESMTPSA id p14sm3442104ljj.12.2022.01.02.17.26.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Jan 2022 17:26:18 -0800 (PST) Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths To: Hector Martin , Kalle Valo , "David S. Miller" , Jakub Kicinski , Rob Herring , "Rafael J. Wysocki" , Len Brown , Arend van Spriel , Franky Lin , Hante Meuleman , Chi-hsien Lin , Wright Feng Cc: Sven Peter , Alyssa Rosenzweig , Mark Kettenis , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Pieter-Paul Giesberts , Linus Walleij , Hans de Goede , "John W. Linville" , "brian m. carlson" , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com, SHA-cyfmac-dev-list@infineon.com References: <20211226153624.162281-1-marcan@marcan.st> <20211226153624.162281-4-marcan@marcan.st> <8e99eb47-2bc1-7899-5829-96f2a515b2cb@gmail.com> <48f16559-6891-9401-dd8e-762c7573304c@gmail.com> From: Dmitry Osipenko Message-ID: <4a307f13-0bd3-5fa5-dd51-9cd1d39eaa33@gmail.com> Date: Mon, 3 Jan 2022 04:26:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 03.01.2022 03:41, Hector Martin пишет: >> There is indeed no need for the castings in such cases, it's a typical >> code pattern in kernel. You would need to do the casting for the other >> way around, i.e. if char ** was returned and **alt_paths was a const. > You do need to do the cast. Try it. > > $ cat test.c > int main() { > char *foo[1]; > const char **bar = foo; > > return 0; > } > > $ gcc test.c > test.c: In function ‘main’: > test.c:4:28: warning: initialization of ‘const char **’ from > incompatible pointer type ‘char **’ [-Wincompatible-pointer-types] > 4 | const char **bar = foo; > | > > You can implicitly cast char* to const char*, but you *cannot* > impliclicitly cast char** to const char** for the reason I explained. It > requires a cast. Right, I read it as "char * const *". The "const char **" vs "char * const *" always confuses me. Hence you should've written "const char **alt_paths;" in brcm_alt_fw_paths() in the first place and then casting wouldn't have been needed.