Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp203074ybz; Thu, 30 Apr 2020 19:46:39 -0700 (PDT) X-Google-Smtp-Source: APiQypJNIOUw+/juXheeUkWyYFZB/X3sV1FZVkP3k/65n1NSwW2kiLTRKDDvbdcnnSgN8fHgk91y X-Received: by 2002:a17:906:560b:: with SMTP id f11mr1300385ejq.264.1588301198892; Thu, 30 Apr 2020 19:46:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588301198; cv=none; d=google.com; s=arc-20160816; b=HC4GZo2f3IP0oBfJc5bUHex9/eQotfbTetqh5WSpLFyVQRfML3t4iDOc26kpkpMFTb PpX9ChOXaYCOPtZllzROzfcnMXKI2icEUAZlL04RFxueCokQRvJsOnG7QVnk5BTAq2S2 s5U9T0u4RVKkwy90gQlIChHJg6infQodsl3ZBzK+0xHCoH9UyYYorTZw7DXXgZv7qpsR 2uak9IHfc4wG8Ytt9x38NtyShck/tRgGZ4/riwbh8e3q9jBOndo1cUJPNq6+VbAdsQoL Fe88tvYdGkcQQIKd9WoSlT2HvwfkUwL9v8pRhYdngOqC2owqSMkhCv45q86TMKsi1yaa xrdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=Yv6XF6USJ+xu6Tv4+Uj+Wn6rEGcoZeH4kUVCy8mqA8g=; b=E4JBmLZcQIyzlVDvavZUH4qkwFTjrTqX0/lEFgpoayM1qT3OWDGvGdzsHtGDU0Sl1Z s7mrSE+Lmgjlw94l6rsR3JJ3wMMlF5GPqnyi8gab24hJfNyRJz81U8xUVPEgWI4gGKEM e4KlcWzlei/hcKy2Kfe7QPgZznwf88+v+VgXroMNLBhDsOxG59iJI2fe2kVCMKSokdix cjOduu4cIvCMLnp1R4cCzvn2p9Bab3lcN5qfq+jSL1SSRtbYaChfScqvK3D/NuZwCXuN NnrjcAorxO8nfke3sHd4OM3UuX6ya0YBYwND7eS1r6T0RudRExi0gTH6AgWCVfVXFRpd AbYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k27si973706eja.340.2020.04.30.19.46.14; Thu, 30 Apr 2020 19:46:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728140AbgEACmH (ORCPT + 99 others); Thu, 30 Apr 2020 22:42:07 -0400 Received: from netrider.rowland.org ([192.131.102.5]:51521 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728107AbgEACmH (ORCPT ); Thu, 30 Apr 2020 22:42:07 -0400 Received: (qmail 21059 invoked by uid 500); 30 Apr 2020 22:42:05 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Apr 2020 22:42:05 -0400 Date: Thu, 30 Apr 2020 22:42:05 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Arnd Bergmann cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Yoshihiro Shimoda , Subject: Re: [PATCH 08/15] usb: ehci: avoid gcc-10 zero-length-bounds warning In-Reply-To: <20200430213101.135134-9-arnd@arndb.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Apr 2020, Arnd Bergmann wrote: > Building ehci drivers with gcc-10 results in a number of warnings like > when an zero-length array is accessed: > > drivers/usb/host/ehci-hub.c: In function 'ehci_bus_suspend': > drivers/usb/host/ehci-hub.c:320:30: error: array subscript 14 is outside the bounds of an interior zero-length array 'u32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds] > 320 | u32 __iomem *hostpc_reg = &ehci->regs->hostpc[port]; > | ^~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from drivers/usb/host/ehci.h:273, > from drivers/usb/host/ehci-hcd.c:96: > include/linux/usb/ehci_def.h:186:7: note: while referencing 'hostpc' > 186 | u32 hostpc[0]; /* HOSTPC extension */ > | ^~~~~~ > In file included from drivers/usb/host/ehci-hcd.c:305: > drivers/usb/host/ehci-hub.c: In function 'ehci_hub_control': > drivers/usb/host/ehci-hub.c:892:15: error: array subscript 256 is outside the bounds of an interior zero-length array 'u32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds] > 892 | hostpc_reg = &ehci->regs->hostpc[temp]; > | ^~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from drivers/usb/host/ehci.h:273, > from drivers/usb/host/ehci-hcd.c:96: > include/linux/usb/ehci_def.h:186:7: note: while referencing 'hostpc' > 186 | u32 hostpc[0]; /* HOSTPC extension */ > | ^~~~~~ > > All these fields are colocated with reserved fields that I guess > refer to the correct field length. No, they don't. > Change the two struct definition to use an unnamed union to define > both of these fields at the same location as the corresponding > reserved fields. > > Signed-off-by: Arnd Bergmann > --- > include/linux/usb/ehci_def.h | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h > index 78e006355557..8777d8e56ef2 100644 > --- a/include/linux/usb/ehci_def.h > +++ b/include/linux/usb/ehci_def.h > @@ -127,7 +127,8 @@ struct ehci_regs { > #define FLAG_CF (1<<0) /* true: we'll support "high speed" */ > > /* PORTSC: offset 0x44 */ > - u32 port_status[0]; /* up to N_PORTS */ > + union { > + u32 port_status[9]; /* up to N_PORTS */ This array can have up to 15 elements, meaning that it can extend out to offset 0x80. > /* EHCI 1.1 addendum */ > #define PORTSC_SUSPEND_STS_ACK 0 > #define PORTSC_SUSPEND_STS_NYET 1 > @@ -165,7 +166,8 @@ struct ehci_regs { > #define PORT_CONNECT (1<<0) /* device connected */ > #define PORT_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC) > > - u32 reserved3[9]; > + u32 reserved3[9]; > + }; > > /* USBMODE: offset 0x68 */ > u32 usbmode; /* USB Device mode */ As you see, this next field actually lies inside the preceding array. It's not a real conflict; any hardware which supports the usbmode field uses only the first element of the port_status array. I don't know how you want to handle this. Doing #define usbmode port_status[9] doesn't seem like a very good approach, but I can't think of anything better at the moment. Maybe just set the array size to 9, as you did, but with a comment explaining what's really going on. > @@ -181,11 +183,13 @@ struct ehci_regs { > * PORTSCx > */ > /* HOSTPC: offset 0x84 */ > - u32 hostpc[0]; /* HOSTPC extension */ > + union { > + u32 hostpc[17]; /* HOSTPC extension */ Likewise, this array can have up to 15 elements. In fact, it's the same size as the port_status array. > #define HOSTPC_PHCD (1<<22) /* Phy clock disable */ > #define HOSTPC_PSPD (3<<25) /* Port speed detection */ > > - u32 reserved5[17]; > + u32 reserved5[17]; > + }; > > /* USBMODE_EX: offset 0xc8 */ > u32 usbmode_ex; /* USB Device mode extension */ Alan Stern