From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07C4536C9EE for ; Tue, 24 Mar 2026 10:49:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774349380; cv=none; b=EePij1uE5tMmjeiItwN1e5H9hNEp+lof7P8LoGVNB2WM/7SN8t0bcjfrSPJRr/Pe6wRkN41a06cDxIpyFhEx91U8tK9+9UI1S1kk8WfMB0tSh+UDEb1sGn6X/KMs/ZlrvQBkXMNjMdYFh79t0HeJri6JrnjDq1Gy1BjjuHROK+Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774349380; c=relaxed/simple; bh=bBTJ5cVFY36aRWUdg7XZBVb400xp1s5RUrHzVP9Wi6Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=S+5HHyakEDjAfM0JP2xgJ/uaqiiayZdRWw8xzi1k4QmFdinfIMiYZ2A7a7Az+XHPXNfjbyHSEHo5Vw7H/iPGlRc17rjL/CeDiQyE5C4eDWmWS4paiuBKO6GawZ8lPO1umdPUb2u5LuxEgbn/JDxdL+/RZVTHlyMv3bP+YqnlqFg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=iz0uPplx; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=bHe1qYUb; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="iz0uPplx"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="bHe1qYUb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774349377; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sHtTZ1ATMReSeQxj1Xnlx1wjJusDT0LtDKqx9YtxfEA=; b=iz0uPplxpoDGxW3GsV6FKPC/nyLH7OJFMdHxNQHfNF+d3vXfhr7DQbLredemYt6HZj1xpU mE/qUkMnRWjrUOZEyUg7XUsfkGIwkuhGNa0zcEzdGmtCwB0d4wlmQGKh34dcdped+UjM6m YSSFsE1y/A+7z8SqOgmJ/gygAJj8Ykg= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-302-KMSg35t8MCiPK7wRamFbZQ-1; Tue, 24 Mar 2026 06:49:36 -0400 X-MC-Unique: KMSg35t8MCiPK7wRamFbZQ-1 X-Mimecast-MFC-AGG-ID: KMSg35t8MCiPK7wRamFbZQ_1774349375 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-439c794ec8eso4208886f8f.1 for ; Tue, 24 Mar 2026 03:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1774349375; x=1774954175; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=sHtTZ1ATMReSeQxj1Xnlx1wjJusDT0LtDKqx9YtxfEA=; b=bHe1qYUb36WuIuL2aFy0yosugG112H/XPt9APf7t47+32MTmu+fnReEkSQZtqlq/Sl gmaZ2HHoELaasDAFLe0Rg4uxjxeDw69ZFBSlf8wyndLrmHC9ky7Xj1X35j1FkPjzH4TU o/AkTvE7GIbexFvldZ3vIBt4bNPqMh4qi7y0ybaEsL5N4y5jsMV8JHa3gnrIEo0uqUut ZSEtuWEfwAMB3dDJ7FTtJtKt+OjFXXsXs/G72F2QU0cYO9VtiE3WsRQcciqasvpE5luK 78+5n4JY5tRHgP9aqCgw3beVyUK6DE7BkKTTrF5S1gypkNgLVp5cFplTrKLkyUmpq0db WnQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774349375; x=1774954175; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sHtTZ1ATMReSeQxj1Xnlx1wjJusDT0LtDKqx9YtxfEA=; b=IsqeYCixlT/xIDQ0LAXv0NIhjENK4CZBz+qwM22VaQRcC8uoGdhk8Wh9VPzzyvKNYr DFurDs9lmS8K/V4VUR2gSERSixuXMZi5716lNPENbmp3KqcIXfFKkshR5hcJ/ZUaEHOD SRZDfFVBFgU4oz/PJsefULcMfsQnCLZBhIAPI1a9RJTK+pEK+UqFLWhH940mbMmK2apQ q5LRdvKVKsxMWkeYq8LjZI+sQnldzbVuhrecVy7CpOMGdmG/EePLy6sVGYjHfA1rnwyH 3fKN7urIX9lbzT5IHaawamvUfIfJE47Y5QqCD7pW+F1Tu/ii6RL0R/2zU2Hird7n9W3M 4DXw== X-Forwarded-Encrypted: i=1; AJvYcCWdnExU42oO2u+RLF4cjJDt0IgGVuZ+RebG3Nyv/9vEa6JqLGx0q7zWdrpiqKzwW1C7JKSCAs93yCMTMnw=@vger.kernel.org X-Gm-Message-State: AOJu0YwkD8ozq1TVJJ+gsxC3opgq94dqPklldCU31Ivi8nwhxiayge/k 7pKC1zZjyH9TlRNR/A3YxsKT3zjAPSAoil31TJIfBPU8wtKqmMIYSrXYtVwUwIk7EVNS9hb5yg6 A8xlqOodV+Ib8yQ3x4VRk2OjbkBwvB6HHCkGlt/IrT9BaIdnt6xQeilZVWElxkM2Eow== X-Gm-Gg: ATEYQzz0+fAzxOE0Vksce9qj4lIU8wHXOq81NHR2EHcnRXLg85ysHopIzag9wV1aShU tfs6yGWJ9dMYkMx9cSh8f5M08Dftl7Qf5t/KaJ0WiVc3FhPf/+M5kZIwqY1qo0jHV8WaOVkwr1j pOKuvdwweI8BZTeEZiEHOyLO3hn8PR1XKt1AIMoUrFdtiGBXQn2M2OiJx/NyuWE3czg6JuU2MUi d7coRWD72ACcZ7BSsFOf/n/ZHGEMjTd1WILHhoipf6m8dN7ajs/zryJ6n7vpFIQfK/sFcDnzr1m X2CbZPUQKXTBnb/OpqbFOC5bDQ9VL299JhhpMlaHEzMQACjFBskyOHN8YZS6EgIeDQHgN2IPi0U HRE9zLNxiWQh1iqZvlQGAh98MhkSABNGtB15kXKqp8QfLBlRIcyqr8DCL X-Received: by 2002:a05:6000:1861:b0:43b:4396:6738 with SMTP id ffacd0b85a97d-43b6427b2c2mr24403825f8f.50.1774349374708; Tue, 24 Mar 2026 03:49:34 -0700 (PDT) X-Received: by 2002:a05:6000:1861:b0:43b:4396:6738 with SMTP id ffacd0b85a97d-43b6427b2c2mr24403748f8f.50.1774349374089; Tue, 24 Mar 2026 03:49:34 -0700 (PDT) Received: from [192.168.88.32] ([212.105.153.60]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b647120a1sm38624039f8f.30.2026.03.24.03.49.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Mar 2026 03:49:33 -0700 (PDT) Message-ID: <6f1e98b3-4b86-4b7f-8c91-d8d5721aeb25@redhat.com> Date: Tue, 24 Mar 2026 11:49:32 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 3/3] dpll: zl3073x: add hwmon support for input reference frequencies To: Ivan Vecera Cc: netdev@vger.kernel.org, Arkadiusz Kubalewski , Jiri Pirko , Prathosh Satish , Vadim Fedorenko , linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org, Michal Schmidt , Petr Oros , Simon Horman , Guenter Roeck , Jakub Kicinski References: <20260320105915.149068-1-ivecera@redhat.com> <20260320105915.149068-4-ivecera@redhat.com> <964752ec-8e6d-444a-aad0-80da3acb2dab@roeck-us.net> <7dbb5130-72cf-49d2-bfac-3439deb1b2e3@redhat.com> <20260323154825.1a2320c4@kernel.org> <50a1671c-9901-426a-97ed-bf36400fe9a7@roeck-us.net> Content-Language: en-US From: Paolo Abeni In-Reply-To: <50a1671c-9901-426a-97ed-bf36400fe9a7@roeck-us.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/24/26 6:16 AM, Guenter Roeck wrote: > On 3/23/26 15:48, Jakub Kicinski wrote: >> On Fri, 20 Mar 2026 14:48:01 +0100 Ivan Vecera wrote: >>> On 3/20/26 1:21 PM, Guenter Roeck wrote: >>>> On 3/20/26 03:59, Ivan Vecera wrote: >>>>> Expose measured input reference frequencies via the hwmon interface >>>>> using custom sysfs attributes (freqN_input and freqN_label) since >>>>> hwmon has no native frequency sensor type. The frequency values are >>>>> read from the cached measurements updated by the periodic work thread. >>>>> >>>>> Cache the device ready state in struct zl3073x_dev so that >>>>> freq_input_show() can return -ENODATA without an I2C access when >>>>> the device firmware is not configured. >>>>> >>>>> Signed-off-by: Ivan Vecera >>>> >>>> "frequency" is not a hardware monitoring attribute. I understand that it is >>>> convenient to report it as one, and that other drivers implement it as >>>> well, >>>> but that doesn't change that. >>>> >>>> I understand that the code lives outside the hardware monitoring >>>> subsystem and is >>>> thus not in control of its maintainers, so you can essentially do >>>> whatever you want, >>>> even if it is wrong. That doesn't change the fact that it is wrong. >>>> >>>> However, do _not_ try to add it into the official list of hardware >>>> monitoring >>>> attributes. I would NACK that. >>> >>> Understood. I recognize that frequency falls outside the strict scope of >>> hardware monitoring and does not belong in the official hwmon ABI. >>> >>> I'm using it here as a convenient way to expose these specific driver >>> metrics, but I hear you loud and clear. I will absolutely not propose >>> adding frequency to the official list of hwmon attributes or >>> documentation. >>> >>> Thank you for your time and for reviewing the patch. >> >> Guenter, should this be a debugfs interface, then? >> > > There is nothing that prevents the actual (generated ?) frequency to > be reported as sysfs attribute attached to the chip (spi) driver, if > it is indeed of interest. If it is of interest for all dpll drivers, > it could be attached to the dpll device, the chip driver could make it > available via dpll_device_ops to the dpll subsystem, and the dpll > subsystem could provide a common API function (such as the existing > temp_get) and generate a common set of sysfs attributes for all dpll > devices. > >> Also an hwmon noob question - isn't it better for the monitoring >> interface to report frequency error / instability in this case >> instead of absolute value? Or do you not know the expected freq? >> > In the hardware monitoring world one would have min/max attributes and > one or more alarm attributes. I never heard about the idea of reporting > deviations, and for typical hardware monitoring attributes it does not > really make sense. What would be a "deviation" of a temperature/ > voltage/current/power/humidity sensor ? Such attributes typically have > an operational range, and they are allowed and even expected to > fluctuate within that range. Ivan, my take on all the above is that using the HWmon interface here is stretching it too much. I think it would be better to move debugfs and/or netlink events. /P