From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f53.google.com (mail-oo1-f53.google.com [209.85.161.53]) (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 A760617BEB8 for ; Wed, 18 Dec 2024 20:53:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734555242; cv=none; b=Y6iRCY31lcFoMUw9Mg68p+sk13oLEtnfnBmb/ZyHyvRsI4q611DNdyPhxwGpBOBvjurWZFzWPIotoVs1xLc2/WMxIvX++7lHzgh0I/M7bxXw0FNzk5S8mJuLdD2NXvUYwgGw8jZ79R2hQyJULRNA2/HBCPupPfDuyZwE7dogH1E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734555242; c=relaxed/simple; bh=knev79UANFUZAIdGmXUO2SJjhZxyJ1aU8kCfLHYZQVw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cE62eH2EtnOGDHcyeLekgqXVtrfpOrV5xLWdvIYuRvEmSPub9HcxhFNqwjuoDgh/+HkS3uVyUZmWYy382ncaVJood8SpfYk58pUOQfnqQd8kX8J3MbnJ3g6bT4K8XEhrw/Xw8tIQBP7Wbr/2yWpP7GR0Ejlg55FXkGTvTaF+ROg= 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.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=sLOYUzKZ; arc=none smtp.client-ip=209.85.161.53 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.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="sLOYUzKZ" Received: by mail-oo1-f53.google.com with SMTP id 006d021491bc7-5f2e370bb3aso9936eaf.0 for ; Wed, 18 Dec 2024 12:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1734555239; x=1735160039; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0acojO1+gNhjMt+ObDwyLasMCvHKTdlCGugB58ry4JY=; b=sLOYUzKZkgw3rIA2VF+LonPj0SqvRb8cmNOCDty7ysh5OpN8kGT1JpMhZ8V3kgnDwq EmQwYjdFg1/qMRnNxylWDq5bvhwsbmIpCrPTh2xv6SAh2+BGeG7v0KRHl7/BbVpElN0/ o5t14SRXcjPLj0x9wj3HPpu1Tj/TRv6ji3NI0woVQMtrmG8vjxbWIHpQZ7QBCeBHPO1y LhSbSX8Jp2heI2Dz7wMnNotAPV4XWV8x89jtimHWfQ5XD7NZMzG26ZWxKLgZq2LLXdci AXiXeCzH9opJa0eMAH5C0U6niA21CNDzGOsf2tHBVrnbMsmCgKoV+DZEm8yB0HMr7RB5 PfBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734555239; x=1735160039; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0acojO1+gNhjMt+ObDwyLasMCvHKTdlCGugB58ry4JY=; b=dvkYgag0agl5kruOZ0jRsldDqfqFt9DIUC7rEUSy3ZWFfNrZfkiLiBi7f72rXS6kIo uRwK7s1cXZss+WYcD5QB5gZiXde7L19FG2dyG1WE1xthl4+INtv0XaNiN+kErnnpiiWl 40GunxuH1zFoRxbeu1HPsJ8G1W6NmCly6aToRcZHXPzXPHY1wZJc6urrwpaU3fJ0Tgv+ elQ+Nzg3oN0A3JcRTeaEAt5CgyEo/lzxsP7PJTxpNuVwd+Uhh3skHcrq+LK20oMLMi2Y VOzCL4oucOsCALJ5iddGNUwCpA4Ti4IxyVC01ZiRD429gcvlJeuek4M1n4AK2xnaw4LZ R+ow== X-Forwarded-Encrypted: i=1; AJvYcCXwRgHOx73RqqXsr8vGZlGyr5r6XkV+xeSWD3BcFlRaih4PJ+c3tVTTYLlrFLUJWLlktGPu5X1EhY2roiA=@vger.kernel.org X-Gm-Message-State: AOJu0YzU1ox7xjJQjfZt71OrETrfqSh4psOoZaCGAwu68YriTLxv3Kbl NfGfeR89v3pfq/+bIdWupisS+UrLZnL+FfDria9VQl9lp+k+KZOF45mfjdTdl8E= X-Gm-Gg: ASbGncu1tXBzxGeI4gPiD0NQv/BgFP9S42lwKrgnNoW61YVkVkKcAIMxetTD5WohXf4 945PELGBtFYSgHdh/WG8f6EGJG2INZ5XXo3LJs7TkMb7opRwWDMVW1F/CYwOuuSrrq62Nuac3IY l7QudRFWZha3nu1vlr+vegk6wk5RQiP2SlVYqUf1RHiTcpV7t9XD3RPQcmudmJRgXPJbp38nRSk 1E1QvNF2/Fiy4NOEf0gYkw9zqTcGC8dGy0sKcKCKJbOdxEoaGqhivYYTx4lAp7D8A4s/8xCMNnU YI37E6PwqBkVbj5RgQ== X-Google-Smtp-Source: AGHT+IE+Q4kvlehpGtXMxI99sieRh9Ap4fOdAJ7eTGygibKbYaU2XuiT+nkDWHmmwm4NzOjQ7KF8RQ== X-Received: by 2002:a05:6820:2292:b0:5f2:d99a:5170 with SMTP id 006d021491bc7-5f4c9b19ce6mr2428247eaf.4.1734555238795; Wed, 18 Dec 2024 12:53:58 -0800 (PST) Received: from [192.168.0.142] (ip98-183-112-25.ok.ok.cox.net. [98.183.112.25]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-71e48307dfbsm2781420a34.4.2024.12.18.12.53.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Dec 2024 12:53:58 -0800 (PST) Message-ID: <296d9e03-1153-4589-95b8-87195d7bbdef@baylibre.com> Date: Wed, 18 Dec 2024 14:53:57 -0600 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: iio: dac: ad5624r_spi.c - use of scan_type To: Matti Vaittinen , Matti Vaittinen Cc: Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org References: <3f5ff01b-8c32-423f-b3cc-a95399b69399@gmail.com> From: David Lechner Content-Language: en-US In-Reply-To: <3f5ff01b-8c32-423f-b3cc-a95399b69399@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/18/24 2:38 AM, Matti Vaittinen wrote: > Hi dee Ho peeps, > > I started drafting a driver for a ROHM DAC. I took a quick look at the ad5624r_spi.c, and the use of the 'scan_type' -field in the struct iio_chan_spec puzzled me. > > I think this field is used by the driver to convert the data from user to register format while performing the INDIO_DIRECT_MODE raw writes. I don't spot any buffer usage. Furthermore, as far as I can say the 'sign' and 'storagebits' are unused. > > My understanding has been that the scan_type is only intended for parsing the buffered values, and usually when the data direction is from driver to user. > > I suppose I shouldn't copy the ad5624r_spi.c use of scan_type to a new driver. I'm somewhat tempted to send a patch which drops the scan_type from the ad5624r_spi.c, and adds the 'realbits' and 'shift' to the driver's internal struct ad5624r_state. This, however, will change the interface to userland so maybe it's best to not do that. > > I wonder if I am missing something? (That wouldn't be unheard of XD). If not, then at least a documentary patch with a comment "don't do this in new drivers" might be Ok, or how do you see this? > > Yours, >     -- Matti > I think scan_type is a convenient place to store this information even if buffers aren't implemented. The struct is there whether we use it or not, so might as well use it. And if buffer support is ever added, that is one less thing to do (removing the duplicate fields).