From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f43.google.com (mail-oo1-f43.google.com [209.85.161.43]) (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 65D8437EFF8 for ; Wed, 17 Jun 2026 21:43:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781732603; cv=none; b=SqNnROIAo3UaHwS7i36DylSOuNFr7nQIy+b8jCMSuHZt1knw9Jjq3J3rcWZmxVZD9OEkrdyqz6fxgwxK8NnraFd+be/JnoNWnqufJ/12EMZUDdRvp9OlAkaCoeUMsF2RZ7vj7RSvXovkZE5kCSx7y1WgoGBe8qWNsFxco4c9NCc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781732603; c=relaxed/simple; bh=STd49iieVtEz/Mng/F8+k4bjVOlJZ0xuDkER0yL5GTQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jn2/qSzqzKPloZGoMlTG/uNjm0EWvMftgdn56o7EnaOfjjuAkR9DeqK5S4Wd/wdu1Ym9Qpn2p7WZJuvMEh0WnRn8Ebm0vH2ikYUDwe/70fis28TcZWcasfLXEvyJJk41/c0VY3K6txxGW988tXJo/j3Mv6uN+5PUyizKi8w2zJQ= 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=d9GHL7KT; arc=none smtp.client-ip=209.85.161.43 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="d9GHL7KT" Received: by mail-oo1-f43.google.com with SMTP id 006d021491bc7-69e1f777bcaso235984eaf.1 for ; Wed, 17 Jun 2026 14:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1781732599; x=1782337399; 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=moLf1HfI30fPHYhYl3mY3kuDIYItGKUlS6CPPB51Qa8=; b=d9GHL7KTyxsmYAH/hZulR6JqiSCDRJYTA7O1/h5l83Kj5Z4oP9+aSXHOhTzCSA4grA yjYL4lTjWKJOnW66s7lYNPZSh87bkt5wBJbzAx8pvbs3YryrDCUuvKnToySXjQaJu86q O0b7iHAtFnYPGs0qEM/sfIMo4pj/lWEd/85I5QzL5unUomqMzjYV4fUzPFqUWGiLvDHX 9HlaTi8Ak+mx8fSdYGA92uQOvXpnRWHeL+R8kLs8pC7j8t0KXmC1B7uT3G24uTIMR439 8ghl9FkxXs5fj3LveZTRhqIcBNrTDiO0gRp6DHMqOYqGDYwT2cF8H2Q/kqq8Jcv4Cpuh 9o3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781732599; x=1782337399; 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=moLf1HfI30fPHYhYl3mY3kuDIYItGKUlS6CPPB51Qa8=; b=Tt/a5TTJrgsu0c4kXvYGvZwHxYnV1Vfif9vcpBNs3tV1j+auWpqU093MoT8ZLCNSca UTzY6UwpwiwGGnYMLLgAcal57RZYuMqn+1+IQYwmbMOQip5LpUaVHTi/7o+yx7McVlgE 7C9HbQdEpkUwgjCiPiTCH8PcCSh4G3bU3XLMDOmER8UjLyqxsQ+NL9IlRBnQVjJQkEwX 0WXiJIJYzrQSrCL7sKAnq20b4GgXfbnsW8j6ThMk00KLnW/BBJ9ZZFg7MH6QBIvtGdp0 yii7fWghM7chDqMNkuHK9gDyErYRlifxwkUz0YJHg3mhfhcr+RPSbjABxvYeG1oLtMbz FMaw== X-Forwarded-Encrypted: i=1; AFNElJ9aXa0ARdU6eh+jRu6U5bpMaWfuWMvHD8Gg5aRanW+5L30oa/JpDKejGU5Ivb3MUzu1fWwPDHNzgrcvNrY=@vger.kernel.org X-Gm-Message-State: AOJu0Yxpx3N/1f+tiIIy6iXlEZ+KaZB+B6I7SMi1YOzWXXtCxZEJcCHG n2NvjKMXpVgALEDL3x4y2rcmlTNyw03b3W2xSL1T8B2hMeJwvGwcMh1hhGEEx99MVRmKZ6mW0qu EACrGir8= X-Gm-Gg: Acq92OFNwiZ/UrWeJGDr7WtEs4F+tx3kVwacL9o0vTprJSq/JQ4KwPccEMruiyvsVVd yCMeaR6aoi52QuEm5St6zRqYduLz1cQ3ib24j/EcR0PAovOP2Sq6SaOkB/zrChbIRLB4+R78bFr 6sjcwCUNKtnn76a/QwIZ7hAh/Z62o133BRn4WNzFGY659k7/bfFxAFlaMOIgic1bfXwkSf5u1ll 5kJnfhSNYRTKvd0sSRTNK1lu+1ljBfLhK81IcG8MpTQVoIAxPw1F3nYeZxos8TF+pFbbsuvyFL+ mvnBpNYk3RVQ2h0avkNDuW2QsjtmIKW8slo3QDutZJ021hSm9prQ+zzfX3NVU4KwIgFB18WL6Qz QAQtL1JV6PnC/CYmmy9BfgNm8LEfdYiTb61CTAgyyRsiNI66FJPU67MgKsc6tBAC4M8QwqSrQ8q 66AjN6tf6yGBe1aY1r2CVpHS2RwvofuLV9m9GG5Vcp9RGlNhGGiTRGmFlkud+RCqPQtHXmasCv+ g== X-Received: by 2002:a05:6820:16a2:b0:69e:b86b:1a9b with SMTP id 006d021491bc7-6a0c73eccf8mr742417eaf.25.1781732599378; Wed, 17 Jun 2026 14:43:19 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:9458:d356:778c:22ac? ([2600:8803:e7e4:500:9458:d356:778c:22ac]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-44308b0057csm5540529fac.8.2026.06.17.14.43.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Jun 2026 14:43:19 -0700 (PDT) Message-ID: <3b96ec10-b022-4135-9ade-6fd9eb6e78a6@baylibre.com> Date: Wed, 17 Jun 2026 16:43:18 -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: [RFC PATCH v3 3/5] iio: buffer: Extend DMAengine buffer interfaces to take extra sysfs attributes To: Marcelo Schmitt , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: jic23@kernel.org, nuno.sa@analog.com, Michael.Hennerich@analog.com, andy@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, pop.ioan-daniel@analog.com, marcelo.schmitt1@gmail.com References: Content-Language: en-US From: David Lechner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/16/26 9:03 PM, Marcelo Schmitt wrote: > Some devices using DMAengine buffers are connected to extra hardware that > allows setting how fast data is transferred to/from the buffer. However, > those extra pieces of harwdware are external to the sensor chip such that > supporting the transfer speed as a sensor property is a bit of an > inaccuracy. Expand IIO DMAengine buffer interfaces to take arguments for > extra sysfs attributes, enabling the transfer speed to be configured > through the buffer interface. This message is a bit confusing. It sounds like it is attempting to control something about the DMA controller itself. But based on the later patches, it looks like this is just so we can add arbitrary sysfs attributes to the bufferX directory. And in this specific case, a sampling_frequency attribute. > > Signed-off-by: Marcelo Schmitt > --- > New patch. > > Now that I've come to this buffer "solution", I have pretty much convinced > myself it would be better to instead have some sort of IIO trigger to control > the signal source connected to SPI offloading trigger module. > In the other chips with SPI offload we've done already, we just used IIO_CHAN_INFO_SAMP_FREQ to control the SPI offload trigger rate. Any reason why we can't do that here? In the original SPI offload discussions, IIRC the general consensus was that adding a trigger just to control that was overkill when I suggested the same.