From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C6F8299943 for ; Tue, 4 Aug 2026 07:47:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785829681; cv=none; b=MdkFTSulYVoXhGzRKHRcoTIlp064z8oaW/47grKXV3Thw6RK0D9nKjWWOhBYRmQPs+3bfAWifpdpmK/uw+DVZbD4Ob0pJVU05QtMB77oKH9a8CMKcWvvVDq7Eu2bJDoaX5adxVruWCR0/86J1A8zs0+iOfIsIeagjqSvz6NJUrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785829681; c=relaxed/simple; bh=nU+W7SDGH97PdLGSIseaAXJGwba3CvLcyXPysdkGHSM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HNTgupQs7GOctY7hhyX5OMP/4YdWOWsmA9jsWqaJYxUnVPjALoxaVDl0+yqJmG4fBA8/QAI6SM8Yqi0pv38OgbuBxosIo+9YlZMcrNU6yC+8f2zs+GVbvz4ZyL3yAur2AjijoxEXslPZvyr1nRC9H5F+uwYgYiG74Ul9W+GN5TM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=aiX+GEyi; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=ZDDiLalw; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aiX+GEyi"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZDDiLalw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785829678; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=S2JCvWdBkPduFfWzd+eDY+HHzmDvS+I5il57IMK4KfU=; b=aiX+GEyilgyBeK99bCr6hKj5aS6ycT6GR+8NoDjVy+naQxdsXlo3YQFuifonn+VakegZZn k084kMTAQc+/DtmaZPaSL41xO9JCGSnsDT44hJpucukcjx4cO7VlVhXDSejq1PLVnGmDB2 OjLhxD+GfgLJBpSohE8tiElajqPgJEE= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-671-p7flcfQMOrmvkpfOOGhA9Q-1; Tue, 04 Aug 2026 03:47:57 -0400 X-MC-Unique: p7flcfQMOrmvkpfOOGhA9Q-1 X-Mimecast-MFC-AGG-ID: p7flcfQMOrmvkpfOOGhA9Q_1785829676 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-473ac08a6a4so3327675f8f.0 for ; Tue, 04 Aug 2026 00:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785829676; x=1786434476; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=S2JCvWdBkPduFfWzd+eDY+HHzmDvS+I5il57IMK4KfU=; b=ZDDiLalw8pJRqK2iy/r+CRdCpJ5MA9jaP3wMkhC9nBl8PzuvALjg3ARlZ0IKaMJZtv Avy6MYCHMZqNI6iBQZigwdEGe1MJFmBnPLvDgiosGYslfyauB+8xIkttPWQFBAxNfXju fe7hb+oF55xmRLOVa76FBhxxhbJIxl0iZ6+9jg8YQrmUfHwrQFpjrwGAfNsmWgci2Zno qabSJbUMzIHkxfZfDOsPydBmPC2my5fgvmeHfZl9j6b+hyQG+SES/T+AcF4txQXMAG/Z i80riJm8hMFvM8pp2J+/hQlCZW6T1OSRd8+p1X6UIrQH2mZ8YEgFDXHSN3QGnMvtB2cA uBew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785829676; x=1786434476; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:from: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:content-type; bh=S2JCvWdBkPduFfWzd+eDY+HHzmDvS+I5il57IMK4KfU=; b=eSEuYMlGUwF6WotwHX9cwBrh25BtKxZtT7JGoV5lzu5Pg9jSuj+3PcwKyLznXb+19+ riGLeHkAixa4JMq5v24g7iDixfUJiD8Zf+wRtITm2k2XY+UOxk+ePwdWlCVZOIS6yrHX 1d6ro2xG8KhSLqi/0pdOMaiqvsgS42DC56pHCJFMYCdD5f04+OQ8u9ewEpydHyWUMxn/ JZbJyCt6lWMOzxQCOG0YbMig3fNibcWOv2aCaCjMN2lAPNmxhdv4qVvfYGus/jfga90t PAu6i2SqciTiM9YDjVQn4RF8TFypniv4zKm37FsPl54gcKDZgVpUR3RJ3yvdeflWgJFO D6xw== X-Forwarded-Encrypted: i=1; AHgh+RoxBBalIxOg+xwAmT7NnoY8CEu3nYa9Zdgu/lwqrLP7LxFbKxWcCVhAmXVQFfWPo0NOCfSIiJpdjAUpX3s=@vger.kernel.org X-Gm-Message-State: AOJu0YxX8KcqjPi8w04qal8QkGFl0kX/zGB2U3Yie0QsCoBm49xXy5TU Rrkhl7PpE4rBVXagSnfMr+SjOYzoTaVHFhvPUF2VkHTXop4Hkn8zFQs6P6qqymsCqhhefQzKVP7 GA7A7JkIsSh3XP4DbEqwaRGleGOSeWBmxQo0IcDkYd20qJAEJNkFP88IrCNMfDHKt9A== X-Gm-Gg: AR+sD11/Q9SiZQ1ubLvMsrRufecscifPQEc02mA98HPg+qZgPqtzaSj1REfhc5RjUUQ fzb8C1ZwaiExnPZfXNSlaGzpXgfZytHiV7Q3sN3gWULDffBi/kgD+2fId5z7AiK0HLaM1uPu6lw ye4w2ZyODj7Jm3N7DEoFTkBuGHs15tHbOTRhiki5GlK5ytjtmVMf3RDCya9vjDSby9ZBKk6SNHH vbm5hHCNxPLpeIWbsEbFtW0hluGY7C63+68z0khLzjlYis7IzCyO8tvcMYSOH56dgrOL2jd5fQY VQPiJD3tDFrMv7/MnIGCtcP99BHRUo5iB771kYJwm8LEWlmQo2VIsBAVH4lajqgCHVnrrQeQ X-Received: by 2002:a05:6000:2208:b0:47f:d072:87d8 with SMTP id ffacd0b85a97d-47fd7257d77mr35665450f8f.0.1785829676104; Tue, 04 Aug 2026 00:47:56 -0700 (PDT) X-Received: by 2002:a05:6000:2208:b0:47f:d072:87d8 with SMTP id ffacd0b85a97d-47fd7257d77mr35665375f8f.0.1785829675678; Tue, 04 Aug 2026 00:47:55 -0700 (PDT) Received: from [192.168.0.9] ([47.64.115.28]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd41e2abbsm41552388f8f.9.2026.08.04.00.47.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Aug 2026 00:47:55 -0700 (PDT) Message-ID: Date: Tue, 4 Aug 2026 09:47:53 +0200 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] crypto: eip93 - use struct_size() and flexible array for ring allocation To: Rosen Penev Cc: linux-crypto@vger.kernel.org, Christian Marangi , Antoine Tenart , Herbert Xu , "David S. Miller" , open list References: <20260803224028.87631-1-rosenp@gmail.com> <8e0dc8db-bfb7-40f4-b6f8-fc773e8b74f1@redhat.com> From: Thomas Huth Content-Language: en-US Autocrypt: addr=thuth@redhat.com; keydata= xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/ WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04/08/2026 09.18, Rosen Penev wrote: > On Tue, Aug 4, 2026 at 12:11 AM Thomas Huth wrote: >> >> On 04/08/2026 00.40, Rosen Penev wrote: >>> Embed the single ring as a flexible array member in eip93_device >>> instead of allocating it separately. This simplifies the probe path >>> and uses struct_size() for a single allocation. >>> >>> Assisted-by: opencode:big-pickle >>> Signed-off-by: Rosen Penev >>> --- >>> .../crypto/inside-secure/eip93/eip93-main.c | 6 +---- >>> .../crypto/inside-secure/eip93/eip93-main.h | 22 +++++++++---------- >>> 2 files changed, 12 insertions(+), 16 deletions(-) >>> >>> diff --git a/drivers/crypto/inside-secure/eip93/eip93-main.c b/drivers/crypto/inside-secure/eip93/eip93-main.c >>> index 1a8dabc4ada4..e62785952b0d 100644 >>> --- a/drivers/crypto/inside-secure/eip93/eip93-main.c >>> +++ b/drivers/crypto/inside-secure/eip93/eip93-main.c >>> @@ -415,7 +415,7 @@ static int eip93_crypto_probe(struct platform_device *pdev) >>> u32 ver, algo_flags; >>> int ret; >>> >>> - eip93 = devm_kzalloc(dev, sizeof(*eip93), GFP_KERNEL); >>> + eip93 = devm_kzalloc(dev, struct_size(eip93, ring, 1), GFP_KERNEL); >>> if (!eip93) >>> return -ENOMEM; >>> >>> @@ -436,10 +436,6 @@ static int eip93_crypto_probe(struct platform_device *pdev) >>> if (ret) >>> return ret; >>> >>> - eip93->ring = devm_kcalloc(eip93->dev, 1, sizeof(*eip93->ring), GFP_KERNEL); >>> - if (!eip93->ring) >>> - return -ENOMEM; >>> - >>> ret = eip93_desc_init(eip93); >>> if (ret) >>> return ret; >>> diff --git a/drivers/crypto/inside-secure/eip93/eip93-main.h b/drivers/crypto/inside-secure/eip93/eip93-main.h >>> index 990c2401b7ce..5f0f51081743 100644 >>> --- a/drivers/crypto/inside-secure/eip93/eip93-main.h >>> +++ b/drivers/crypto/inside-secure/eip93/eip93-main.h >>> @@ -92,17 +92,6 @@ >>> EIP93_HASH_SHA224 | \ >>> EIP93_HASH_SHA256)) >>> >>> -/** >>> - * struct eip93_device - crypto engine device structure >>> - */ >>> -struct eip93_device { >>> - void __iomem *base; >>> - struct device *dev; >>> - struct clk *clk; >>> - int irq; >>> - struct eip93_ring *ring; >>> -}; >>> - >>> struct eip93_desc_ring { >>> void *base; >>> void *base_end; >>> @@ -131,6 +120,17 @@ struct eip93_ring { >>> struct idr crypto_async_idr; >>> }; >>> >>> +/** >>> + * struct eip93_device - crypto engine device structure >>> + */ >>> +struct eip93_device { >>> + void __iomem *base; >>> + struct device *dev; >>> + struct clk *clk; >>> + int irq; >>> + struct eip93_ring ring[]; >>> +}; >> This looks weird, too. If there is always only one "ring", why don't you >> embed it without the "[]" into the struct eip93_device directly? > keeps all callers the same. -> vs . So it's basically keeping the patch small and generating many WTFs for future reviewers of the code vs. having a bigger patch now and better understable code in the future. Not my decision (it's up to the maintainers), but FWIW I'd rather go with option 2. Anyway, if you want to keep it short, wouldn't it also be possible to declare it as ring[1] instead and then keep the sizeof() instead of the struct_size() ? Thomas