Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1038080ybz; Fri, 1 May 2020 13:11:59 -0700 (PDT) X-Google-Smtp-Source: APiQypJO5lPnE2DqUw4PBi+1bwoCcuz4mM/Ja3+VJ+PVXd/mRkTmadHsyS+3NZmk126zU1yxuxzr X-Received: by 2002:aa7:d413:: with SMTP id z19mr5160961edq.80.1588363919251; Fri, 01 May 2020 13:11:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588363919; cv=none; d=google.com; s=arc-20160816; b=y0ZQoMNOgXThrbS3qrzCDz+GMOKJ4rxW0NLL++QRSoqbc6Bjsy/lk3YR2WwUqnlBSp 5TMkcJqf2hkLqyZyXc80PuAK09yASjIXmBraOPWpjiLq+73o3Qy5o5YRQ5j6BXkRvTsZ 0FZlYffOMBOlXTYCH5xpSTDx5bXAXGosbLffaGBmYcL8fKKY62Tj0LwUjA9hEfATThnM 0VsuLH8nZPC17Va0G8TLAIDE7yEFSUbnEFhMBILsTHoi+1kedWH38hswCia3vgP2FGFh DZt6hCGaOJi/dqYi2rh66Ig/GuKvr2c6l63Vbht3Dmiq8M5P+mgAw/Z09ExZPdFSbvmT /sYg== 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=WPvH8E2s6Y3yhFfoETD7PTrIFYNGugGDwrdnF4DjlrU=; b=r34HkXAL1jY6deqPnPg8qRFxR0actCC0KE357x7J7ylwMnIgg528Mhwji8L/PuDyKx xi0Lw0tdqRY+m6oB4fQVGNL2xHk83TOokYhRFZ0l9YzwavpHzYU1lWwFEbH3NXEmyQsN F54NAkEy/fL7mBNnGHIKS6LW2b7jivKxVkIFIQlNQnttffoZdHa/UNWd16jLnEgV1E5Q hy6Urm1soM/Pq1ff+cUMcLgwRZnF5l4qEPKYx6SprBhCVKomdaB89boSiQP2FR/NXuK8 tX7PKu5zAyA6K3C3CmH38Yoadjae32MqcoEOtMLllofEvkBJWUJMOk26+P82DpXuSanE WpyA== 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 j19si2200110ejx.382.2020.05.01.13.11.34; Fri, 01 May 2020 13:11:59 -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 S1726558AbgEAUKE (ORCPT + 99 others); Fri, 1 May 2020 16:10:04 -0400 Received: from netrider.rowland.org ([192.131.102.5]:35739 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726307AbgEAUKE (ORCPT ); Fri, 1 May 2020 16:10:04 -0400 Received: (qmail 2454 invoked by uid 500); 1 May 2020 16:10:03 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 May 2020 16:10:03 -0400 Date: Fri, 1 May 2020 16:10:03 -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 , USB list Subject: Re: [PATCH 08/15] usb: ehci: avoid gcc-10 zero-length-bounds warning In-Reply-To: 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 Fri, 1 May 2020, Arnd Bergmann wrote: > On Fri, May 1, 2020 at 4:42 AM Alan Stern wrote: > > On Thu, 30 Apr 2020, Arnd Bergmann wrote: > > > > > No, they don't. > > > > /* 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. > > Ok, thanks for the clarification! > > > > /* 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. > > The easiest change would be to use an anonymous struct like this > > /* PORTSC: offset 0x44 */ > union { > u32 port_status[15]; /* up to N_PORTS */ > /* EHCI 1.1 addendum */ > #define PORTSC_SUSPEND_STS_ACK 0 > ... > #define PORT_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC) > struct { > u32 reserved3[9]; > > /* USBMODE: offset 0x68 */ > u32 usbmode; /* USB Device mode */ > #define USBMODE_SDIS (1<<3) /* Stream disable */ > #define USBMODE_BE (1<<2) /* BE/LE endianness select */ > #define USBMODE_CM_HC (3<<0) /* host controller mode */ > #define USBMODE_CM_IDLE (0<<0) /* idle state */ > > u32 reserved4[5]; > }; > }; > u32 reserved5; > > It doesn't really improve readability, but it should correctly > reflect the layout as you described it. Sounds good. Please go ahead and update the patch. Alan Stern