From patchwork Sun Nov 6 19:30:18 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marijn Suijten X-Patchwork-Id: 16169 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1643919wru; Sun, 6 Nov 2022 11:34:54 -0800 (PST) X-Google-Smtp-Source: AMsMyM7NogYLDzX8PJl+m5hL0cW2fqV0Zf5r+XIJCbFuUCt6Wj/Dea3K4LiqCdMamQPh1gMQ8iI4 X-Received: by 2002:a17:907:6e9e:b0:78c:5533:4158 with SMTP id sh30-20020a1709076e9e00b0078c55334158mr41859680ejc.417.1667763294582; Sun, 06 Nov 2022 11:34:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667763294; cv=none; d=google.com; s=arc-20160816; b=T2HlHrvfWBbeRGJR7hn4NoOvkbp1SZJnJjvqmXIrD3muLdm0DSjMA3s8L8LELUl9c4 Z09ui5cvq4cLdNb8tZMEhKqRRZGO0jBaSk7RoH0mTawnf5y56BNWCxC0j8TrZE/TKtvU TKGL4HwbGAnecp3Arf40CGj2ZqAVhd09A1Z1fF8uzqu1V+R+FJ649ArT/jhyuTh+S1HB o+hqOph8/U6RQjSqc6vyNB3VO6eN+kzfqSRmiZrXd+1HLvjDGLcJR2aFQ7nbeDTM1q0P B2+1+Fd4pyByqQ82kwBXbh3hK8+VRn/JVauFdhXGts8kFFrXz52l5BMdyGZ1K7u/ohaL gPtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=jAik7ewO0nO7jgq6FGpgBBZJNe+BMkvNSwkXzVdDy08=; b=n50Pbg0dpeMETnOPK+PzDDujWRKliH9Nemw1Jk393cWrV4BJ7srWjRbRGATq/tsXim YwiHQQifg9tGpuKc4AS/oDWLQfZnrX7bV9kKQo46n/W5KNoPcn6aTTu4iM5fH/7u6m6T kKX9WwkLYG1IOJtPq68PpgHrZabBkAiE+uyNY3aRaaqriCT3YlrydprpZvtsd/PIR2gM bgd8Fx2cU/iXdjjsNP+P0HyZ2LeFeexyT9qRO0uv7yr56VdPuPStWSo3yYYiycA/F1MI VjZmp5Bmb917UwzY9xsQnAOYS1wwEypOKzbVvfb3ufydtSiyOKC5APoA5NGU9Q3kI9IT Rgtw== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hr3-20020a1709073f8300b0078dcfe6a000si8300856ejc.727.2022.11.06.11.34.28; Sun, 06 Nov 2022 11:34:54 -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 S230011AbiKFTag (ORCPT + 99 others); Sun, 6 Nov 2022 14:30:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229787AbiKFTae (ORCPT ); Sun, 6 Nov 2022 14:30:34 -0500 Received: from relay03.th.seeweb.it (relay03.th.seeweb.it [5.144.164.164]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B99EDF5A for ; Sun, 6 Nov 2022 11:30:32 -0800 (PST) Received: from localhost.localdomain (94-209-172-39.cable.dynamic.v4.ziggo.nl [94.209.172.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r1.th.seeweb.it (Postfix) with ESMTPSA id D1D381F517; Sun, 6 Nov 2022 20:30:27 +0100 (CET) From: Marijn Suijten To: phone-devel@vger.kernel.org Cc: ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno , Konrad Dybcio , Martin Botka , Jami Kettunen , Marijn Suijten , Andy Gross , Bjorn Andersson , Jonathan Cameron , Lars-Peter Clausen , =?utf-8?q?Nuno_S=C3=A1?= , Luca Weiss , linux-arm-msm@vger.kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH] iio: adc: qcom-spmi-vadc: Propagate fw node name/label to extend_name Date: Sun, 6 Nov 2022 20:30:18 +0100 Message-Id: <20221106193018.270106-1-marijn.suijten@somainline.org> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748776564194667346?= X-GMAIL-MSGID: =?utf-8?q?1748776564194667346?= Much like the ADC5 driver iio_chan_spec::extend_name has to be set for friendly/useful names to show up in sysfs, allowing users to correlate readout values with the corresponding probe. This name is read from firmware, taking both the node name and - if set - node label into account. This is particularly useful for custom thermistors being attached to otherwise-generically-named GPIOs. Signed-off-by: Marijn Suijten --- This RFC may seem a bit controversial as there are multiple patches going around in DT-land changing how nodes are labeled [1] (or introducing new ones: [2]), seemingly to appease binding conventions without considering how the driver propagates them to IIO (and in turn what userspace sees in sysfs). I hope we can put together the right conventions with this RFC. Before getting started, note that ADC5 provides this DT/FW node name/label in *both* extend_name *and* datasheet_name; adc5_channels::datasheet_name provided by the macros remains *unread* (except for a non-null check). Since the names hardcoded in the driver seem to be somewhat "datasheet"-y, and the names in DT typically take the form of a more friendly "-therm" indicating where the thermistor (or voltage probe) is located on the board or attached to, I have opted to persist the original use of vadc_channels::datasheet_name in iio_chan_spec::datasheet_name, and only propagate the data from DT/FW into extend_name. (We should likely rename vadc_channel_prop::datasheet_name to extend_name to this end.) Back when I submitted patches for pm6125 [3] (utilizing ADC5) 4f47a236a23d ("iio: adc: qcom-spmi-adc5: convert to device properties") didn't yet land, and these patches use the node name to convey a useful/friendly name (again, the string literals in ADC5 are unused). fwnode_get_name() however includes the `@xx` reg suffix, making for an unpleasant reading experience in sysfs. With all that context in mind, I feel like we should answer the following questions: 1. Should we propagate names from DT/FW at all? 2. If so, how should a node be represented in DT? Should it use generic node names (which we might not want to use anyway considering the `@xx` suffix highlighted above) or labels exclusively? 3. If only labels are going to be used in conjunction with generic node names, should ADC5 be changed to ignore the node name? 4. If a label (or node name) is not set, do we fall back to datasheet_name hardcoded in the driver? 5. What do we use for datasheet_name vs extend_name? 6. Any other vadc drivers that need the same treatment, when we come to a resolution? [1]: https://lore.kernel.org/linux-arm-msm/20221031181022.947412-1-luca@z3ntu.xyz/T/#u [2]: https://lore.kernel.org/linux-arm-msm/20221101161801.1058969-2-luca@z3ntu.xyz/ [3]: https://lore.kernel.org/linux-arm-msm/20220926190148.283805-1-marijn.suijten@somainline.org/T/#u Thanks for considering this! - Marijn drivers/iio/adc/qcom-spmi-vadc.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) -- 2.38.1 diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c index bcff0f62b70e..8c6c7fa13cfe 100644 --- a/drivers/iio/adc/qcom-spmi-vadc.c +++ b/drivers/iio/adc/qcom-spmi-vadc.c @@ -84,6 +84,7 @@ * that is an average of multiple measurements. * @scale_fn_type: Represents the scaling function to convert voltage * physical units desired by the client for the channel. + * @datasheet_name: Channel name used in device tree. */ struct vadc_channel_prop { unsigned int channel; @@ -93,6 +94,7 @@ struct vadc_channel_prop { unsigned int hw_settle_time; unsigned int avg_samples; enum vadc_scale_fn_type scale_fn_type; + const char *datasheet_name; }; /** @@ -652,7 +654,7 @@ static int vadc_get_fw_channel_data(struct device *dev, struct vadc_channel_prop *prop, struct fwnode_handle *fwnode) { - const char *name = fwnode_get_name(fwnode); + const char *name = fwnode_get_name(fwnode), *channel_name; u32 chan, value, varr[2]; int ret; @@ -670,6 +672,12 @@ static int vadc_get_fw_channel_data(struct device *dev, /* the channel has DT description */ prop->channel = chan; + ret = fwnode_property_read_string(fwnode, "label", &channel_name); + if (ret) + channel_name = name; + + prop->datasheet_name = channel_name; + ret = fwnode_property_read_u32(fwnode, "qcom,decimation", &value); if (!ret) { ret = qcom_vadc_decimation_from_dt(value); @@ -771,6 +779,7 @@ static int vadc_get_fw_data(struct vadc_priv *vadc) iio_chan->channel = prop.channel; iio_chan->datasheet_name = vadc_chan->datasheet_name; + iio_chan->extend_name = prop.datasheet_name; iio_chan->info_mask_separate = vadc_chan->info_mask; iio_chan->type = vadc_chan->type; iio_chan->indexed = 1;