From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f43.google.com (mail-oa1-f43.google.com [209.85.160.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 8DF6C32D0D8 for ; Mon, 27 Apr 2026 15:21:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777303301; cv=none; b=uTFOGBbTHRKP0UfJbOTQwAaldvoYUB4W5cKaNjUn6Esw1EJzaPJxiWmAI5D2DpbQ1zViSsdor4gHQulJorQPnShhCfmKGhg2hAaT7UN3It555/4g1hfoaJ7qZSt7VVjp1cw6WLgeQG7/Yayhh8AwGv1B7HZVLQFJMUpNEZFxVeY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777303301; c=relaxed/simple; bh=ULJRQV3E0UINpZ1bQ6syPJdZBgATZCzncKAoETZPhlA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BFflQjMHZcxBLoHVbTkcFPTrPoj9ykKOcHYScF9I2zTIPIJBUr6Lo7YPv8CNIPCt7SWa87MhTwoAyezywX+iHac2Iv+ZVdmSxrDicbQY1vLUqr1cOMo/L8XSJ6G7hq1cdMbJpV/I9pUUFY1MFHZQvgsnxSpvgaohEo1coVGmIzg= 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.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b=Hhw+4aUz; arc=none smtp.client-ip=209.85.160.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.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b="Hhw+4aUz" Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-40ee9b945d5so8449728fac.0 for ; Mon, 27 Apr 2026 08:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1777303298; x=1777908098; 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=sNFqGLWNs6epgqAb2w7dNNEwLLcehXWUO7S5uBl+hwk=; b=Hhw+4aUzBcTV1hDgs5N5xFRQ2SALxYr3raY9ClvPMo7VEnSodkyyBstIr59zdhCjBj 9sVb1w/GXDkHZZ+TPgxKTcqg0vWdLhNWxj8oYwsFESjZFTqwEEZSabkQGpm9QziGm5lY X7qikf98TcBlIq0KSb3RuyxjBmeDcr56c+F+MeeaA3LS1izPzzpGVAOXsEKp9/eMLLuc yscXj8mTYQaqirGmomNzSPUfK9m5rDvI7u+0JdQsLfuiMfcCnEPtgguM/GhCQBWzP4A8 24khAZ5tZNtJTnYedILJywfzNO7M7LzLsK2u7KZu587VszynXaGVx+1Rm0so3xW93uMJ Uhnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777303298; x=1777908098; 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=sNFqGLWNs6epgqAb2w7dNNEwLLcehXWUO7S5uBl+hwk=; b=OSmDzk0uip4SvgtQ+0cmW3VvETg3YIP6DLHpALHYZ0iWmx54GaAahgeJ5BQTX1lU6R 1MI5ElR/hICBXaHNhIAXNM0d5r+jRxG4d76K0QE/wfa7OL1fiUxeVOeNg56Ub33Z4/56 TQxQ8t0V0WQI/0NIdQhzetbzuiT0uhEli7iP0dFIQ2lo5JUDetY4hOP1TZGB1eshhGAq OV9RC1P6pxqp4OlIT4ZxsEq+S2T4k7kQ8BNoyn2mX6JsjuyrHv93OaNWEdxXUynXM5cS vmJm/6mZadMUocdfD979tpKdA/LlangE+k5JyLdPifHB8XNO1WSBxe+zcatq54M4g1nz tLvA== X-Forwarded-Encrypted: i=1; AFNElJ+Md38v1SuI4rSdYzeFlACg6HBuPtqiCNBbYQipFgURcB9F+AOjM2wJ1a3rOP7Pl0CvYaONo8yRx6d9p1w=@vger.kernel.org X-Gm-Message-State: AOJu0YxZKPjLDXUVrUvvf70ns+1NQDykn8ghgR2DG0d6nLAo0l1aC95e QS55zCy0hrEIi6wwYuk18DvXTd5jO693T4Q0ZZdw/h8i+UtipgMJPlAT8iIX++82JvI= X-Gm-Gg: AeBDievRbr7t7LcCxsxaYFQ3xsO0rpO6Lvh+UYC9UaWNu8m9dnU4joy0XI4xXvfU6QK NFEwwMO0eLfL84NBHUEPeTY+uItkI9FrEsAUCIe3735QLx4QX6rqBgXeesFCVEbSVSB1d0SENzK szHy5YupZ1aLazYL/C4kjhk/fr7rmdLAFB/W9Ha6VDxqIl+kCDU7bWKyrzLEnKvPMS8l8k/i/lo ISsP2hW3HFgzhc1CRelSgxfH2mFupMaThz8rFMC4JEwqrsJ9HH0cQjxbYKl0yWuVcdguEFp8Lm+ RF7nWYBCo2Jlw9WU06xreq8yh4Oj6XPReeA1bXathoPNuV0uknJ84bb+uQp0rLArnD2kc8Z0myN 9Feql3lmhqA79kcee/EPJ4QGmD3j1+iL7UsWVch3qnwq9yao8Own6P/b83b0jC26Hn+0rW0t90z /4BlQ6chvc2v28SB0jmgzFQjtx0MxOQE+4gOkEdkWwQuWcDdZcFibHUuin4E2OnAy7smc/sk2UD K74YYEQ+ynk X-Received: by 2002:a05:6871:80e:b0:417:4693:ca0 with SMTP id 586e51a60fabf-42abf2e029cmr25519053fac.14.1777303298554; Mon, 27 Apr 2026 08:21:38 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:96f5:eee9:c87c:c599? ([2600:8803:e7e4:500:96f5:eee9:c87c:c599]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-42c16b64a83sm21928789fac.18.2026.04.27.08.21.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Apr 2026 08:21:38 -0700 (PDT) Message-ID: <3512cce0-6660-42a9-91bb-07e78a002205@baylibre.com> Date: Mon, 27 Apr 2026 10:21:37 -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 v2] iio: adc: ti-ads7138: replace kmalloc() with stack allocation in i2c_write_block To: Giorgi Tchankvetadze Cc: antoniu.miclaus@analog.com, lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org, nuno.sa@analog.com, andy@kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Jonathan Cameron , Andy Shevchenko , David Laight References: <20260427112705.71138-3-giorgitchankvetadze1997@gmail.com> <20260427143137.27bc4552@pumpkin> Content-Language: en-US From: David Lechner In-Reply-To: <20260427143137.27bc4552@pumpkin> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/27/26 8:31 AM, David Laight wrote: > On Mon, 27 Apr 2026 15:27:07 +0400 > Giorgi Tchankvetadze wrote: > >> The ads7138_i2c_write_block() function currently utilizes kmalloc() >> to allocate a buffer for I2C transfers. However, the length >> parameter passed to this function is strictly 2 bytes across all >> driver invocations, making the total payload buffer size exactly 4 bytes. >> Invoking the heap allocator for a 4-byte buffer introduces >> unnecessary SLUB overhead. > > Have you confirmed that the buffer is never used for DMA? > > Provided the lock that blocks concurrent access from two threads > is actually outside this code, a buffer for short transfers could > be allocated within 'struct i2c_client'. > > David > Giorgi, This is why it is important to include a changelog and a link to the previous discussion [1] in the cover letter or after --- in a single patch when you submit a new revision. I think that would have answered David's question. [1]: https://lore.kernel.org/linux-iio/20260424081809.61841-2-giorgitchankvetadze1997@gmail.com/