Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp55648pxb; Tue, 12 Apr 2022 16:39:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7CaLfyv6EPRwLPcaaEV4vBOMETQf6GXMCzHEqrSi/tc5HJyksO0HAVRMwIGpV4QDss8Wn X-Received: by 2002:a17:902:9b95:b0:151:533b:9197 with SMTP id y21-20020a1709029b9500b00151533b9197mr40395542plp.66.1649806788239; Tue, 12 Apr 2022 16:39:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649806788; cv=none; d=google.com; s=arc-20160816; b=ec0T25UoCdAQkzxI9hnnAR1R4T9s/VnvTyOKRuO8zbd4sW3V3BZw6NiaEKTPD5G6AW lL0H05qxia3Mgu1/Uscaj+JDcAQEF/nNEOcOFwnYiY2Xo9PXy0zKCkhBIdqYu2kpTL+0 0dVhpE4BJ+zfh0p49wRnrUR8Too5ZzVmtKJz12ZRp78xMC/Gbd8bs0IZDaKeM+bdNVgb /7ZDWksOmPxzrHR+FjmPvIDZGOMoB5KV8r+e0fzml5z63qsBD9U7lChgFVry7sjzQmWf tMcf94OsWgd0GbZUnCu8v+w8E6TfERRR54WbD2iJL1Mk3Dy/SphHhIu3e9i0l9HBBz/v RcdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wQ2qCdwNBzGPgm1nvc6+W2Rhv822rMMuuPhosO1N7f4=; b=fJiizyBqpbcME8gfslb9tJQLpo/yzxGRUw4KlH3+B+C54kefeDtiTj/6xJynT2JZ/P MVHhXXMnO9+ChfkV/0IcljFSqhtHt9c+Dq6RGOQFAu8X0UkFL1RNK8hQ6dWiBIF72PzP k5PfHKM6L5c9jU0QNywEEXF7jWBX5tDwG8n0D0BmZV4e0MD9qPAwrolJORPd/srLDl0L QNzg3VK7SByRIPVECgt4wZbOXNc6f9XRy04Fms/DRHHUMl72UkvPEM/BzOrQm5+Tj96e +kiyagT9LHJKsgHMfEY+LkHVz4s28eecST6gPyTk6zOnLDgcsjIvm4HkEy3VgV+BfLBv Txog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=XBsvbAIF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id e11-20020a63aa0b000000b003820d821f00si3924414pgf.473.2022.04.12.16.39.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 16:39:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=XBsvbAIF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6A7B8F954B; Tue, 12 Apr 2022 14:31:24 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347150AbiDLE6f (ORCPT + 99 others); Tue, 12 Apr 2022 00:58:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347035AbiDLE6d (ORCPT ); Tue, 12 Apr 2022 00:58:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6865F11C14 for ; Mon, 11 Apr 2022 21:56:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EE2F0617E4 for ; Tue, 12 Apr 2022 04:56:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D03D7C385A1; Tue, 12 Apr 2022 04:56:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649739375; bh=m6VSt+/v92P1Zg4jzcDGMViyz4qsqAMT7JU7EYUuzrw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XBsvbAIF0QEh7W6YUXlTe15h0Z8iar99m1/jK+vE1MRBUmrj0RIvjCPobYTf1BFOd s0bgHJKvz5h/MNww7jnZf5XH0Od3r2VIQTtYRWudOz8l7gD1cc8Xw0qEWqUGArCKIl ITWIyqvUQr4j1ChMzkPezdF/PC+SmZdieWIkK5Eg= Date: Tue, 12 Apr 2022 06:56:12 +0200 From: Greg Kroah-Hartman To: Jaehee Park Cc: Johan Hovold , Alex Elder , greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, outreachy@lists.linux.dev Subject: Re: [PATCH] staging: greybus: replace zero-element array with flexible-array Message-ID: References: <20220411211411.GA2796005@jaehee-ThinkPad-X1-Extreme> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220411211411.GA2796005@jaehee-ThinkPad-X1-Extreme> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 11, 2022 at 05:14:11PM -0400, Jaehee Park wrote: > Zero-length and one-element arrays are deprecated. Flexible-array > members should be used instead. Flexible-array members are > recommended because this is the way the kernel expects dynamically > sized trailing elements to be declared. > Refer to Documentation/process/deprecated.rst. > > Change the zero-length array, buf, in the struct > gb_usb_hub_control_response to a flexible array. And add wLength as a > member of the struct so that the struct is not a zero-sized struct. > > Issue found by flexible_array coccinelle script. > > Signed-off-by: Jaehee Park > --- > > I have a question for the authors: > I saw a fixme comment in the hub_control function in usb.c: > / FIXME: handle unspecified lengths / > > I was wondering why this comment was left there? > > In this patch, I'm using this struct: > > struct gb_usb_hub_control_response { > __le16 wLength; > u8 buf[]; > }; > > And instead of using response_size, I'm doing this: > > struct gb_usb_hub_control_response *response; > And using sizeof(*response) as the input to gb_operation_create. > > Would the flexible array address the handling of unspecified lengths > issue (in the fixme comment)? No, you can not change the format of the data on the bus without also changing the firmware in the device and usually the specification as well. > drivers/staging/greybus/usb.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/greybus/usb.c b/drivers/staging/greybus/usb.c > index 8e9d9d59a357..d0b2422401df 100644 > --- a/drivers/staging/greybus/usb.c > +++ b/drivers/staging/greybus/usb.c > @@ -27,7 +27,8 @@ struct gb_usb_hub_control_request { > }; > > struct gb_usb_hub_control_response { > - u8 buf[0]; > + __le16 wLength; > + u8 buf[]; What is wrong with buf[0] here? You can fix this in other ways if you really understand the difference between [0] and [] in C. Please look at many of the other conversions if you wish to do this. thanks, greg k-h