Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp240404rwb; Sun, 6 Nov 2022 05:28:11 -0800 (PST) X-Google-Smtp-Source: AMsMyM5QgjeoatIXA9Cpw0qE+tV+Az7BSFAk3pC1B3rTZmQ8IGnDf7ioG0BIJy8/Qqlk/WFqlPp3 X-Received: by 2002:a17:902:968f:b0:180:a7ff:78ba with SMTP id n15-20020a170902968f00b00180a7ff78bamr45810110plp.87.1667741291481; Sun, 06 Nov 2022 05:28:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667741291; cv=none; d=google.com; s=arc-20160816; b=ft7rka9pS/xK6Ehf4bBgY3QSZQGfSPTqbUOm9Ptn+CeIA9SmxY0wiZj2JxwN0shj0B m1k192uqEiUGjDhEMKem1k0qfyFYE0e0pXG4HOhwug0IYTDrqn4zqaM+iFir13P+wyOi knj2RpyiaOnFj2jcwf5aKhPMgHsIX9LbKmpLXbTBd6uMsgrCpytayu3a5/DWOpTbJL4L SqSGLSTHyiDbiWT5lyHKxw2fYnVGusx2dVnIfvsbIKACh/QjVh0PB0eQsdg+Ifm4hVFR iJ/KbwIT6LyelG1tJHVgdlTlHzA6+f405RXt4ZJyL+iycs+k09/dJS3O0swGOTnkvMvF H2uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=rtaI7dptqi5ZpwJEZKaaL0yHcZ/jKYlvvRoizfRf0a4=; b=g0HJ4X0Uhe3vzESHRgqHWATrfwucTU5WuB8HnHBfeCGt3P5AGVmAZl4BdN/ZfJxQFz G14ArwaEPE/IJfjsPrZwGFnoYdCXuzuzhL7wHXyAyHp4KdFK5zXHG6tMLXODVjpKmht3 BfsR8NTNa9p5MOIOHCSFmWaXnlJT3gDa+NaMCQVrH41sjJRj3neuJjyelD8xF7czn5Ey jp6hLOX9PlSdSZDmrRaKr80uw/8quyE8DbmsWAkrY23JVxZ3pFl08obKeQ9H2TrQD/K7 dMiafg/96P8VXtaG99Lk9eUkQ9+kZ5aJuHuNcbIWyq2ts8Vkh29D+t3wkXY+8qO+LSdJ FLDQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c12-20020a655a8c000000b0045f83471400si7654781pgt.328.2022.11.06.05.27.59; Sun, 06 Nov 2022 05:28:11 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229939AbiKFMrV (ORCPT + 96 others); Sun, 6 Nov 2022 07:47:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229763AbiKFMrT (ORCPT ); Sun, 6 Nov 2022 07:47:19 -0500 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50A5C634B; Sun, 6 Nov 2022 04:47:18 -0800 (PST) Received: by mail-pl1-f174.google.com with SMTP id v17so8835660plo.1; Sun, 06 Nov 2022 04:47:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rtaI7dptqi5ZpwJEZKaaL0yHcZ/jKYlvvRoizfRf0a4=; b=hZ0xCe/GW5Y0ltXS00gNODyCPC6FA+KEIKiJsRflmcBFDNd7JhRQ0qE0/ExSOqlC4m BdaMcxxj934ELo+qtnTIZr0KlJDVU1omBbuaXXwfyEVPkY9N7Ff4d3rS8TbKT9KTANM9 bYobQjfpC3N4AbgIGkTcFTQzYuLntY7U1lPRQu9r4aFCa7eoCgYXORH7VBRGUwz4Dy9A BdcGIs4DUUwnXv9TEus/ncKRdeLC/rT+aCDKWK4S4tXCuG2KpTiVkOlTUBeRsZFtm/7j oPBW8jxp/TUYxO5D/cEPwlpHGOalyZr7bSJwbASJscHAsfekwVAoPPeSVycrhsbPeVZ6 7PqQ== X-Gm-Message-State: ACrzQf0OM1+XLdDa5humlRh+Gpjf1pN3mtBQZFyaejYdKoF9uJi5jsSS wGiLlY6mAbZsLiHs2SIqdYI9kem7SPvawztts5rxT7gi0Tk5/w== X-Received: by 2002:a17:90b:4ac3:b0:213:3918:f276 with SMTP id mh3-20020a17090b4ac300b002133918f276mr61586630pjb.19.1667738837447; Sun, 06 Nov 2022 04:47:17 -0800 (PST) MIME-Version: 1.0 References: <20221104073659.414147-1-mailhol.vincent@wanadoo.fr> <20221104171604.24052-1-mailhol.vincent@wanadoo.fr> <20221104171604.24052-4-mailhol.vincent@wanadoo.fr> In-Reply-To: From: Vincent MAILHOL Date: Sun, 6 Nov 2022 21:47:05 +0900 Message-ID: Subject: Re: [PATCH v2 3/3] can: etas_es58x: report the firmware version through ethtool To: Greg Kroah-Hartman Cc: Alan Stern , linux-can@vger.kernel.org, Marc Kleine-Budde , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Sun. 6 Nov. 2022 at 20:25, Greg Kroah-Hartman wrote: > On Sat, Nov 05, 2022 at 08:45:10PM -0400, Alan Stern wrote: > > On Sat, Nov 05, 2022 at 06:38:35PM +0100, Greg Kroah-Hartman wrote: > > > On Sun, Nov 06, 2022 at 02:21:11AM +0900, Vincent MAILHOL wrote: > > > > On Sat. 5 Nov. 2022 at 18:27, Vincent MAILHOL > > > > wrote: > > > > > On Sat. 5 Nov. 2022 at 17:36, Greg Kroah-Hartman > > > > > wrote: > > > It's late right now, and I can't remember the whole USB spec, but I > > > think the device provides a list of the string ids that are valid for > > > it. If so, we can add that to sysfs for any USB device out there, no > > > matter the string descriptor number. > > > > No, there is no such list. > > Yeah, my fault, nevermind about that, sorry. > > > > If not, maybe we can just iterate the 255 values and populate sysfs > > > files if they are present? I'll dig up the USB spec tomorrow... > > > > Yes, we could do that. But the filename would have to be the string > > id, which is not meaningful. We wouldn't be able to have labels like > > "product-info" unless somehow a driver could provide the label. > > We could have a directory of strings/ with the individual descriptors in > there as files with the name being the string id. > > But that might take a long time to populate, as it can take a few tries > to get the string from a device, and to do that 256 times might be > noticable at device insertion time. > > > Also, there's the matter of language. Devices can have string > > descriptors in multiple languages; which one should we show in sysfs? > > All of them? Right now we use just the default language for the strings > > that we put in sysfs. > > > > > I say do this at the USB core level, that way it works for any USB > > > device, and you don't have a device-specific sysfs file and custom > > > userspace code just for this. > > > > This is unavoidable to some extent. Without device-specific information > > or userspace code, there is no way to know which string descriptor > > contains the data you want. > > Agreed. > > Ok, for this specific instance, adding the "we know this string id > should be here" as a device-specific sysfs file seems to be the easiest > way forward. > > Vincent, want to try that instead? OK for me. Will do that and remove the kernel log spam and replace it by a sysfs entry. I have two questions: 1/ Can I still export and use usb_cache_string()? In other terms, does the first patch of this series still apply? This looks like the most convenient function to retrieve that custom string to me. 2/ Is it a no-go to also populate ethtool_drvinfo::fw_version? Some users might look for the value in sysfs, while some might use ethtool. If the info is not available in ethtool, people might simply assume it is not available at all. So, I would like to provide both. Yours sincerely, Vincent Mailhol