Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp8068765rwl; Tue, 10 Jan 2023 08:41:17 -0800 (PST) X-Google-Smtp-Source: AMrXdXswjEukSAr2bKo5M5CYspuCESAaTYgqvRvFZhN5X+p2TMO5vkG3MeLm778I/09Pd9A7IleO X-Received: by 2002:a05:6a21:9990:b0:a6:f26b:558 with SMTP id ve16-20020a056a21999000b000a6f26b0558mr106649681pzb.16.1673368877723; Tue, 10 Jan 2023 08:41:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673368877; cv=none; d=google.com; s=arc-20160816; b=ABs4xVTJBxXDztXicwB/qubwdco4ML95B78NG/AE44nDtUDp9fmMiY6Va6ath8lDdG NIYoOSp0ywORw1q5v/cioMPKa8jM8eCR/C9v1wcND46OOd7ubQ863fw46e0WEkEazNCP DxOu1+8nLaMLTZXsb1kVFWJI792r87haxNUCzf2W9KG/xRTHfgklutn6FJjuDmTS1+pc MlxCkiiJG+WYQKBA71iS58A4X9a8LiorSvefS/rXYRR9mFnK4NlKoZ017flBTyeWyzHa foC49Ff9N3RJC0O9mm8+GEwuPXaU8YaTnfR0guHMaikS5j7I/Z/q+qAoDHQod7X8pxFI dfUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=PZryAiOlbPz7sMIp3QxBVwgo2I5e3FTv/Pjyo49AuRU=; b=nDVmdkCu45KItWMEWIMrpSU5wciuhl1lAvJ6xQxDeGYdmY7fTgvxjdl1aPpK/0375z cg1RAr3X6bBn/KJ0Z2vjlT/RLInHtlcsx6+zbHHvvMe0dkj9qLTQVK6rLGLGj7y1QsQL gcqEdkTjCklGPe+B/5eL4Au+JiDguXpcX8LeN5Ptridvp6Gjbd4XBBF6gf1iSQI6QiAN NkhqjOJGbidA0v7opGat0StwbhiMOVt0VlQQmNV2ey6x9oezyyaL/v83zBPjx/mhjogG R2+f5rZ9QrVP+oaSzUMT2ENss9ZT5jgBQVYw84/1q+0es2f5LNFpWqYV0I7ZQeDKpyKA EMGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=iUaDRdgB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i22-20020aa787d6000000b00581f88656f2si10966964pfo.24.2023.01.10.08.41.10; Tue, 10 Jan 2023 08:41:17 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=iUaDRdgB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238820AbjAJQb4 (ORCPT + 55 others); Tue, 10 Jan 2023 11:31:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238529AbjAJQbj (ORCPT ); Tue, 10 Jan 2023 11:31:39 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84FB681D4C; Tue, 10 Jan 2023 08:31:35 -0800 (PST) Received: from [192.168.0.192] (unknown [194.146.248.75]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: andrzej.p) by madras.collabora.co.uk (Postfix) with ESMTPSA id DFF4A6602D7B; Tue, 10 Jan 2023 16:31:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1673368294; bh=gf2SVFXGu/ip2hmdsTFFak6Bv478mdC5jsczhYIQnc0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=iUaDRdgBA8r/cNb9FciggE1Y3/3iPFlNHrF7NrKHEtcSjhWtr4oQU46S7K7at0/Bp /8M5AjmVxNACscme3WknZVAZSVmSfCm7nqf95tcfEAhZiX38Uty/SU9akvcK/eKSGS 09XYRrXl7xhCthCNcz62eo75WS0VfnAI5sbIxFLzUlG/rmvqsO4RdjeTTEDPTE28xQ l7IIvoR/f5FIAU7uK3p/DU44l5tRjBqpzf8v1/ZjdJoJucglA48C0OGFzRuvZAGuQc uMY7eGHoBFNdhzSZVBs3IFFdob+NSRbhC6XijK9sipTFA5sgIK8LAmUmIXwHGVSBR6 BnjoskOtgypOg== Message-ID: <87cab5a1-a122-2b10-43b4-7a5819ff55ef@collabora.com> Date: Tue, 10 Jan 2023 17:31:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH] usb: gadget: u_ether: Don't warn in gether_setup_name_default() To: Jon Hunter , Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org References: <20230106161759.66019-1-jonathanh@nvidia.com> Content-Language: en-US From: Andrzej Pietrasiewicz In-Reply-To: <20230106161759.66019-1-jonathanh@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_SBL_CSS, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Hasn't there been a similar patch already? W dniu 6.01.2023 o 17:17, Jon Hunter pisze: > The function gether_setup_name_default() is called by various USB > ethernet gadget drivers. This function always generates the MAC address > for the ethernet gadget device and always prints a warning when > generating the MAC address. Given that these messages are expected, make > these prints informational instead of warnings. > > Signed-off-by: Jon Hunter > --- > drivers/usb/gadget/function/u_ether.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c > index 8f12f3f8f6ee..c19d66cd1446 100644 > --- a/drivers/usb/gadget/function/u_ether.c > +++ b/drivers/usb/gadget/function/u_ether.c > @@ -845,13 +845,13 @@ struct net_device *gether_setup_name_default(const char *netname) > snprintf(net->name, sizeof(net->name), "%s%%d", netname); > > eth_random_addr(dev->dev_mac); > - pr_warn("using random %s ethernet address\n", "self"); > + pr_info("using random %s ethernet address\n", "self"); As far as I can tell this function is called by all Ethernet gadgets, and using random Ethernet addresses is the default behavior for all of them, including legacy gadgets. Why to inform about the default situation happening? So in fact maybe it would be better to eliminate the pr_warn() altogether, instead of replacing it with pr_info()? If the user does not care to explicitly set some non-default address(es), why would she care to know that a randomly selected address has been chosen? Note that learning _what_ specific address has been chosen is perfectly doable without these pr_info() calls. Regards, Andrzej > > /* by default we always have a random MAC address */ > net->addr_assign_type = NET_ADDR_RANDOM; > > eth_random_addr(dev->host_mac); > - pr_warn("using random %s ethernet address\n", "host"); > + pr_info("using random %s ethernet address\n", "host"); > > net->netdev_ops = ð_netdev_ops; >