From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72A2EC282C3 for ; Tue, 22 Jan 2019 08:08:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 49D8820870 for ; Tue, 22 Jan 2019 08:08:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727593AbfAVIIn convert rfc822-to-8bit (ORCPT ); Tue, 22 Jan 2019 03:08:43 -0500 Received: from mail.bootlin.com ([62.4.15.54]:54475 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727374AbfAVIIn (ORCPT ); Tue, 22 Jan 2019 03:08:43 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id 8D411209EF; Tue, 22 Jan 2019 09:08:40 +0100 (CET) Received: from xps13 (aaubervilliers-681-1-37-87.w90-88.abo.wanadoo.fr [90.88.156.87]) by mail.bootlin.com (Postfix) with ESMTPSA id 1B575206DC; Tue, 22 Jan 2019 09:08:30 +0100 (CET) Date: Tue, 22 Jan 2019 09:08:30 +0100 From: Miquel Raynal To: Masahiro Yamada Cc: Lucas Stach , Marek Vasut , Richard Weinberger , Linus Walleij , Boris Brezillon , Janusz Krzysztofik , Linux Kernel Mailing List , Stefan Agner , Jonathan Hunter , Boris Brezillon , Thierry Reding , linux-mtd , linux-tegra@vger.kernel.org, Brian Norris , David Woodhouse Subject: Re: [PATCH 2/2] mtd: rawnand: use unnamed union in struct nand_op_parser_pattern_elem Message-ID: <20190122090830.118eb6be@xps13> In-Reply-To: References: <1548142975-14219-1-git-send-email-yamada.masahiro@socionext.com> <1548142975-14219-3-git-send-email-yamada.masahiro@socionext.com> <20190122084944.420fcd4a@xps13> Organization: Bootlin X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Masahiro, Masahiro Yamada wrote on Tue, 22 Jan 2019 17:00:54 +0900: > On Tue, Jan 22, 2019 at 4:50 PM Miquel Raynal wrote: > > > > Hi Masahiro, > > > > Masahiro Yamada wrote on Tue, 22 Jan > > 2019 16:42:55 +0900: > > > > > Although drivers do not directly get access to the private data of > > > instruction patterns, let's use unnamed union field to be consistent > > > with nand_op_instr. > > > > > > > Actually this is how we wrote it the first time. Then we got robots > > reporting that anonymous unions where not allowed with older (still > > supported) GCC versions and I had to do this: > > > > > > commit c1a72e2dbb4abb90bd408480d7c48ba40cb799ce > > Author: Miquel Raynal > > Date: Fri Jan 19 19:11:27 2018 +0100 > > > > mtd: nand: Fix build issues due to an anonymous union > > > > GCC-4.4.4 raises errors when assigning a parameter in an anonymous > > union, leading to this kind of failure: > > > > drivers/mtd/nand/marvell_nand.c:1936: > > warning: missing braces around initializer > > warning: (near initialization for '(anonymous)[1].') > > error: unknown field 'data' specified in initializer > > error: unknown field 'addr' specified in initializer > > > > Work around the situation by naming these unions. > > > > Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation") > > Reported-by: Andrew Morton > > Signed-off-by: Miquel Raynal > > Tested-by: Andrew Morton > > Signed-off-by: Boris Brezillon > > > > > Hmm, how come Andrew's compiler was fine with the following? > > struct nand_flash_dev { > char *name; > union { > struct { > uint8_t mfr_id; > uint8_t dev_id; > }; > uint8_t id[NAND_MAX_ID_LEN]; > }; > unsigned int pagesize; > ... > }; > It is probably not :) > > > The current minimum version is GCC 4.6 > (commit cafa0010cd51fb7) > but I am not sure if this restriction is remaining. > That's right, can you please test if this limitation is still ongoing wit GCC 4.6? Thanks, Miquèl