From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 CF4063F44D0 for ; Tue, 7 Jul 2026 10:52:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783421543; cv=none; b=fUyyhAQfc328ZCBvGseGBzTmKOIPhcgcefUHYqm++7wiBBW6XP+KBQlKCDC/yFjCR/exA+puSgABKDT/v76HAKlhLxVB/mdEtTozriTU6G+BZGkKgSUHpWVQJpagId1/SlapZyIoWId7ZHWb7+5yZ6cj6w/BfCTw7K4JlqgtMHo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783421543; c=relaxed/simple; bh=U1qvcFxLKrwEquFjkv7uGnL3tOB3rFVzjZa3qamyz38=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K0+vThhlJDfwcpfjgYWBpq/MHkuMb4ZRVr9ofLI5lzHO6wo772KXgiq+qnpTBSr8yEm2OkIG88BxO+3rYzjmmXyvE/AAHrO+dCns1Hb82rbOjuBOPcFHYPvaWfL1wfKueSO1B0xN9anAC3nKW5T8HFe8cETongc/7k6NWQuuYGc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=D2S6VbhY; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="D2S6VbhY" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-493c7902f47so24694945e9.1 for ; Tue, 07 Jul 2026 03:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783421540; x=1784026340; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=xD/I4R2QXs7s+95dAxGC6Ggop7ankDcEDMFD0oYB+2Q=; b=D2S6VbhYrlD2hqzn8sgapX710ygbTyX9A2BBWrt76Tx7hhh5DriMr8+490ICdkiCFw kH1zKsmQIKmcCUXiNLk12MG1iOpm14y2fU2IweNe8VJx1t46MIXKdYVC/7gcvGVnWcrW swl5DlcYq5R7HYmzehkMvTwdJ9PKINaP8mK8zVIPJkPZIhZrWop5QdklUSAxH1Sij+Su w+f3muko16oxQMzZ9spFWxlN2kg7mcBLb8tXSfauqoGE0s/5rE5iGNdWedxlUvR7GfAa 0BoFpEaTePSRwCvz/IaIg3kiDRaxeFmiwVGv3FP3LnucQs/v3YcwGXDNIhO6N38NkEWh bRWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783421540; x=1784026340; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xD/I4R2QXs7s+95dAxGC6Ggop7ankDcEDMFD0oYB+2Q=; b=Gxu4YQvKwTTeMwQnugoMnGWNLHshXXdU2NRNrb93NNGTFaccXg9mgr0BxNswojy0H9 Gw+ewXI3QvUyf3tAxcZV2NsRzCxRlfdp0QjKopDQ0WoRBEKQliD9bIwWE6j3Pl0zXmaq JzlAQQ+R1TpmzlGOXhIPDeF+7yv3+H7mrU7V1mrBPm0UR/PwxpQbMh9G650QOA/7ZYuz QsSvFfmyVXfNRNgywdh/3k7Ll0stAK/DgPqkQ48LHC1LRDJTiYepcrPYssQn9EcL6UXT 4oW+NDUFz4HQXEmUvSJj9qPLeRC1+Pu3e1jlpxbEKbU3C/pLKapFxD39eM3PMASABZDU 4U+g== X-Forwarded-Encrypted: i=1; AHgh+RoRZXKkwu5wDAkQbxYkBnoVLGfgO5ionDZAKzOwAekWxP9feuiqrYn416MwedmpOZLKpWHvV8koqd2UOO8=@vger.kernel.org X-Gm-Message-State: AOJu0YzigW56M2GdatZVk6ClfATCk1mv9eUuAd/ygCjT7z4sXntig1L9 lRid7/K8VEr2IaFr5DzknckgWFFXH1EGSAKEivddbbdoP8WH9rJuO1bl X-Gm-Gg: AfdE7cmvRbx3twETEDB6OqHBcd8qbPakpQsFUeoJvvM3SfkP5xxEbeRCF7bcWOoG0QB Lgc0qPKaUfcfD4/V9KnbTStfRXCosmGWfrMY4/X5Jgch+dF2Yirk3HjH1xWU1pXWP86HCmiF1yS PeJjdwwVOf3JK6nJkQg17ts9ThzeRMNGgrAf6amIdfaMYNscS60sQFyMVVxSOSVFlONitMDd91Z BTh+P7QupeQJkMmA9ZHgQ4VqfSLeqPReLd3aQGdAQHYc2UcAdOOgUnveRC1o3MYAOTVv3vWKdYI GYK6avXky2ja6J/OfXrFVUQdmuePS0gFh0Hm6BgXom+m6Ge6zpK5jcfewlAvJBfGekGB0RNHK2D qs04tKNSu4GJyBQSTwd5TQkGXVHw+DpTMR3xfTro9nfFEEVg9faQM1uuz14BO8l6PxSnckDR+3G qq1aE1MiP811XTm08= X-Received: by 2002:a05:600c:c168:b0:493:d282:8298 with SMTP id 5b1f17b1804b1-493df052084mr54038025e9.16.1783421539970; Tue, 07 Jul 2026 03:52:19 -0700 (PDT) Received: from nsa ([148.63.225.166]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493df7010aasm40499085e9.0.2026.07.07.03.52.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 03:52:19 -0700 (PDT) Date: Tue, 7 Jul 2026 11:53:24 +0100 From: Nuno =?utf-8?B?U8Oh?= To: David Lechner 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" Subject: Re: [PATCH v6 12/16] iio: frequency: ad9910: add RAM mode support Message-ID: 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> <2d84950f-c56a-48f5-ab7c-c7b7ccb3b28d@baylibre.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2d84950f-c56a-48f5-ab7c-c7b7ccb3b28d@baylibre.com> On Mon, Jul 06, 2026 at 09:10:21AM -0500, David Lechner wrote: > 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. I see! I would still advocate for apps to properly do the matching between the current device id and the firmware path :) But the above is obvious something we can't control. - Nuno Sá > > > 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); > >>>>> +} > >>>>> +