From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f46.google.com (mail-oa1-f46.google.com [209.85.160.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8CA95367F45 for ; Mon, 6 Jul 2026 14:10:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783347027; cv=none; b=bmwogcudnPa+g1SLWTtDSsON51d+m77W5hd/AX5pwmT7yvjH3kBS2bk0Xp/GUnJTD/QaYSpirfMljL0ToQnfOnstdMdvKVuGZwZFgSGUJGkyJm2UJwvlzAZfBr7aT32dAYGMl+lJCA51uTw9PQ1HkNshBZWYr4vVOAyVq0i72mE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783347027; c=relaxed/simple; bh=YOsYyrc/bitTU9Vwq6vnx2DmxDDwMmLL4M4U3a7xGto=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QEDWpm/nP8zsbtW4ec2q4nofSEaZc+pcDlgXSa3qZDqhKTvPg5fE+bJJ56MutZSfim9Yc790abN5ctSaWiS4sxIO3VEMOYidAnzkMxzGenYvngEmgKj5lvb/VRdiPT1f8y3ENfharGRCmdueoBGxNNbfKdxQLh+o8K2XgTLFrgk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre.com header.i=@baylibre.com header.b=BemTA9d+; arc=none smtp.client-ip=209.85.160.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre.com header.i=@baylibre.com header.b="BemTA9d+" Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-44cedfaab6bso899662fac.3 for ; Mon, 06 Jul 2026 07:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1783347024; x=1783951824; 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=8Q13oMYkW312woQm68JTsMT/EHUSwSrALmbtYHd4pkc=; b=BemTA9d+p0hVaw+VZWUV9RDD8Tmrcy8wb0aKRfBZYWTL+6d+v9nTaMMF/+R1Iorf61 vS1c9imyQ34K6uPtXHR9XTuVOSuWwzWd1BxzqQR65Nmn5Z14MWn8d9RMn2iStcZ4WoKO pK0i8QoEQrZGkrdeZ9nLReGOzL52FS3Q8pqAdZiAlASXXy8v/cMApyNrDzW6RC+Tm4KC 4JWGl0Ln/0QHxLwfEABPd7e3KtkvviPRTd1pcnPEyT50oGLHoUNr1CBr4wWUFolqQUoq XDoSq8LnY7Kt8sSATQgPi8lcNBFjQhsTlDmLTnMMA1yx3wSX/PTIXgHPZCYOLEwmwPKm XQRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783347024; x=1783951824; 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=8Q13oMYkW312woQm68JTsMT/EHUSwSrALmbtYHd4pkc=; b=j/8nkodOQoVwPGPGOnhubb4ZpLrbWO4VXA1evWVzdLiIW/i2SQxPCbtoccGQeUwxS/ 2YI7+iBK3hWketB89wL9CdAMSbhqS62nyizkrqXvQhIYnuoqx9d4y8wxhi79NNM8zPWH A5ewF4hsYC9PCGaezPPnD/SaEzr9w/tY6UCqGi+AaD8r444MVlGG4STMxFjJThZLeTtl LsbuT4001F7mNhXUWovVSrV+RuB/DTyKl/HaX0JAJchfC2YbCyT5iQdlHl4EiysbBe+b VL6+k1+NXB1ynyz29wJRK34wDPCb/W7sEuf/wPaEkFDA0advb4Vo9ol9VZypTjRc1PZW Yc0A== X-Forwarded-Encrypted: i=1; AFNElJ8uOK+uh/w5WIDrjoFQpjmt1hCgxMYP6op+GJS4JpTAnRbiWOltd8HqVOGEKnb1EwYblhUP7KsyBEim0Eo=@vger.kernel.org X-Gm-Message-State: AOJu0YyexF40AazL+4BQ6rXehPx+auN5iiob5geWBMV5IWAe2BNh7IKj SeN3tzC2X2Yz2fyL1rrM7dXPayGpxzfSE3831lw6VTYnChy2BlAfcoqdLwmiUvaQPUU= X-Gm-Gg: AfdE7clhfW67p7oeudUWp9jE7hAzomJ0RJll3407tccEcGcZGkO5Z+WDKZIpJ2iXeb7 4vuO9fLqGJd2NDC+5R2uoeQDAbXqVIOu2BGgHAxOVHhrgzAearogYGVXRqjiy6QKUVfBRpwgHYu CjkjWUzA8cEkVlPOcQlmmrJY4ZEDuf4+uVyt2iecHcHwpKwPvxHNZOsaZ3+JRKXPk/aqe9EUbqN FBYt8Jyb0F94i9nibSqomnkA6hGJI9byYE6qWQDlkx7taT+hmDLfV44Z/LRJ7SBwahR8davpCHw GPjq/QMEgivM4RzXLIqM231OzPKNT0X8afmR11VK2rnsE6AA6RbYpHFDSdJ9mEPWXyympRBssLQ 85hd9GAqToY+sxR48t8epUrbSNNU4T490y9kMILmpNlaUhYsbKO7WLxlsl+rnqADrQmaoRccHWy rHfhmVDbBbQ8tfQ+sL5DJSr9Qzo+KuXDaWpvbiUfB3GVBtjZZ4grf5g3eAKlbzZBg= X-Received: by 2002:a05:6871:820a:b0:43b:58a4:cc33 with SMTP id 586e51a60fabf-451065bccf8mr348850fac.22.1783347024487; Mon, 06 Jul 2026 07:10:24 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:a38a:a0af:ed1d:5c77? ([2600:8803:e7e4:500:a38a:a0af:ed1d:5c77]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-44cfb6691d1sm10542741fac.17.2026.07.06.07.10.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2026 07:10:22 -0700 (PDT) Message-ID: <2d84950f-c56a-48f5-ab7c-c7b7ccb3b28d@baylibre.com> Date: Mon, 6 Jul 2026 09:10:21 -0500 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 v6 12/16] iio: frequency: ad9910: add RAM mode support To: =?UTF-8?Q?Nuno_S=C3=A1?= Cc: Jonathan Cameron , Rodrigo Alencar via B4 Relay , rodrigo.alencar@analog.com, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-hardening@vger.kernel.org, Lars-Peter Clausen , Michael Hennerich , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Philipp Zabel , Jonathan Corbet , Shuah Khan , Kees Cook , "Gustavo A. R. Silva" References: <20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com> <20260618-ad9910-iio-driver-v6-12-79125ffbe430@analog.com> <20260703040544.08a8ea5e@jic23-huawei> <1493eed5-5bb8-4a2c-8f2d-8b4bc5dde157@baylibre.com> Content-Language: en-US From: David Lechner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 7/6/26 4:47 AM, Nuno Sá wrote: > On Sat, Jul 04, 2026 at 11:50:35AM -0500, David Lechner wrote: >> On 7/3/26 9:09 AM, Nuno Sá wrote: >>> On Fri, Jul 03, 2026 at 04:05:44AM +0100, Jonathan Cameron wrote: >>>> On Thu, 18 Jun 2026 14:27:28 +0100 >>>> Rodrigo Alencar via B4 Relay wrote: >>>> >>>>> From: Rodrigo Alencar >>>>> .. >>>>> +static inline void ad9910_debugfs_init(struct ad9910_state *st, >>>>> + struct iio_dev *indio_dev) >>>>> +{ >>>>> + struct dentry *d = iio_get_debugfs_dentry(indio_dev); >>>>> + char buf[64]; >>>>> + >>>>> + /* >>>>> + * symlinks are created here so iio userspace tools can refer to them >>>>> + * as debug attributes. >>>> >>>> Maybe worth a reference to appropriate ABI doc here (even if it is introduced >>>> in a later patch) >>> >>> I'm not so sure about these links. I mean, I definitely agree we should >>> make it easy for userspace tools like libiio to be able to handle >>> these kind of attributes but using debugfs is questionable to me. Pretty >>> much because this is not a debug thing. It is a real setting for the >>> driver so ideally we would be able to control it (using the existent >>> tools) without enforcing one to mount debugfs (I know that most of the >>> times it's always mounted but still feels wrong to tie "real >>> functionality" to debugfs). >>> >>> Having said the above, some suggestions: >>> >>> 1. Make the iio_dev the parent so that the attr name is just "ram" and >>> it will be a subdir /sys/bus/iio/iio:deviceN/ram/. >>> 2. Propose a new helper for the firmware_loader code so we can get >>> struct device from struct fw_upload then we can easily create a sysfs >>> symlink. >>> 3. Name the attr as dev_name(iio_dev):attr so that it becomes >>> iio:deviceN:attr_name. >>> >>> Now that I think about it, 2. does not make much sense when compared to >>> 1. And If I'm not missing anything both 1. and 3. can be sanely parsable >>> from userspace (being 3. maybe a bit more reliable). And yes, both require >>> user space tools (in this case libiio) to support a new type of >>> attribute (firmware) but that is another problem. >> >> I would say that udev should be used to find the firmware device from >> userspace rather than creating symlinks. And you probably don't even >> need udev if you already have the `iio-device:` value. The path > > Just one note. If you mean as the attr name the above will fail for > multiple instances of the same device. That's is why a proposed > dev_name(iio_dev) which I think it should reliable be iio:deviceN. My is the same as your N. It looks like I just had a typo of an extra : in there. > > I guess N might change so anyone hardcoding it might have surprises. But That is why I mentioned udev. > properly done and we have a sane way to match the above with anything on > /sys/class/firmware/iio:deviceN:/ > >> is always going to be `/sys/class/firmware/iio-device::ram/`. It >> seems like the same amount of work for usespace to computer the path >> either way, so might as well keep it simple and leave out the symlink >> stuff. > > Yes, at least for libiio, `iio:deviceN` is already what we call the > device ID so we can match fw attrs against it and everything after the > last ':' is treated as the attr_name. > > We just need to keep in mind that if a second user of this stuff pops > up, we should add a new helper to enforce the ABI. > > - Nuno Sá >> >>> >>> - Nuno Sá >>>> >>>>> + */ >>>>> + snprintf(buf, sizeof(buf), "/sys/class/firmware/%s/loading", st->ram_fwu_name); >>>>> + debugfs_create_symlink("ram_loading", d, buf); >>>>> + >>>>> + snprintf(buf, sizeof(buf), "/sys/class/firmware/%s/data", st->ram_fwu_name); >>>>> + debugfs_create_symlink("ram_data", d, buf); >>>>> +} >>>>> +