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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CC03EC433EF for ; Mon, 30 May 2022 12:45:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MCd0I/BY2UWljcEadzTZkhZwYGAiY9pfr00Ns/33utQ=; b=U9jj0jH/oRAYWl AAdsEBy6cj/1/ixZPn6diu4ywKNQnrXHiVaoyvNOh5Y52hYTzyaU4w2tVwI/ZXU+M9GQf6OeWCy7U UDQHfq1fEtvGnRlwOAM2kA8Gq0ZEOzl0tc4BmcTdTQvExpSl+vDhX4PNj4Qjyb729ZMakMLF2enen REl+zyicsCz9BHEx6bzI7velf9ctukZJg6pnG9776owRFIFz4+HNCF1ZsOrTaOIkBwlimPra1KX+T iHeokke1eJPyDjjAyNxDMmU6dUMACqp4OoT6KOJ2oMdBEKmDNLYHz+fuwoHVPp9qh8ZB6hQBDgQWR aTG94bBOIsKi9NPlt11A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nvekk-006YAf-H3; Mon, 30 May 2022 12:44:10 +0000 Received: from mout.kundenserver.de ([212.227.126.133]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nvekg-006Y9N-68 for linux-arm-kernel@lists.infradead.org; Mon, 30 May 2022 12:44:07 +0000 Received: from mail-yb1-f174.google.com ([209.85.219.174]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MTi9N-1oNS7K1HXp-00U0m2 for ; Mon, 30 May 2022 14:44:03 +0200 Received: by mail-yb1-f174.google.com with SMTP id t31so5930165ybi.2 for ; Mon, 30 May 2022 05:44:03 -0700 (PDT) X-Gm-Message-State: AOAM531qCDgsxhrJGlwShodgYE41JmqIKbOULRBTcASD9AN/L1lMgIoc IS+Bd6PN7zLTtPFRkIzsjGQRuLVSESlTE4kls0E= X-Google-Smtp-Source: ABdhPJwGhDH7TTQEFtfKClpkV8v6MgE6/PlkkdchHiAR2sctlXWrlvyx8XgWbwbNazMHWQ8TgK10FAziIIsvzr+V4hc= X-Received: by 2002:a25:9b89:0:b0:655:8454:dc92 with SMTP id v9-20020a259b89000000b006558454dc92mr25317431ybo.550.1653914642134; Mon, 30 May 2022 05:44:02 -0700 (PDT) MIME-Version: 1.0 References: <87a6aztli2.fsf@intel.com> <877d63tleq.fsf@intel.com> In-Reply-To: <877d63tleq.fsf@intel.com> From: Arnd Bergmann Date: Mon, 30 May 2022 14:43:45 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers") To: Jani Nikula Cc: Linus Torvalds , Arnd Bergmann , Sudip Mukherjee , Russell King , Viresh Kumar , Shiraz Hashim , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , dri-devel , Linux Kernel Mailing List , Linux ARM , SoC Team X-Provags-ID: V03:K1:k/Qljy5kO14h+VEOCgbiP6eIBVt56eYGv688l6ABn1vffEbiU8s QLjqbrcwLQZhIwmtK3dexfpUm6dfu3nPEOiFGMUOzvo0K0DTRqbax4a2nwUwNNOsa5QDtMr 5khmaKTFo5QreX1b7QRQEe9GMIIkJPFCFkhOE2ghUoYma+GyYstc2D3j8xrOSu2STCLqNo6 jAUkElJPFVAu9YnGDv+tg== X-UI-Out-Filterresults: notjunk:1;V03:K0:l8JCJpJXsLY=:jMYSpuOrKVb2p5BQ+KDT0+ Ab12kM6aMOhLisqjQgyNbLfJBCseGYE+IPT0cIaNpU/T0TZf+2nDBW8/wX0i8UR3v6MwX0QC8 hTTfpJ/TzMD8ueZit+vFwdJdM1nivrFwk0scBcoPtGQiS3lgx2BUjNiLLmMcdLGWkGImSQwRu MRaQk5V6ZAR4H8V5YECkIzlyoW7kV37lQavfRo2k7rp8I1vIWQDgK6L4/y7Td6c1NDON43ZlU CJ369FdK7bCMAsDB/K1UXETiuZ+AmnxwBIgoIwgoc1EsKN9zX+2X3OafVwy1eWMC0yhY2WtPR OwZfWeGQp91GuvyzNxpVg7HeMc8P4NvXeWjuozR8GmmxJjkg1axpg1yBe9dkv/42zQnsX7dtc tLPHWLs6Ni2Z0ScErTlAuv8q3EC44jj4jGKblxKLSuQP7V8Bl70r9JXKLig7uEwqA04Qh04R3 rVo1o2SHUxOR0yzyqJKh4SBqVOYvx2xAcXj+tqNnhuYTDkIiOCTXhlOKO3mYyQvwxyNvzZutv Bem1rGmVdDiVWMOeGQQu1IMk99u3qkTr4KwcDl5KQG49Bnn6hT4q0Di3yDadJogXr5wvqnhdQ K2diABde8LWJQR1vZ9Cld17gj/FiMm4PRpMTHeZYnKapQvmWHM5f8Ae/B54K0FxuueNdPVJbS 4/zs6kZUP8FX3G5RwnJx46eV+CM6hGSr0avg/+5Y1WrAyxE9yIE0xusWRCQk3UJ+j9EX4X7ph t48m84grggEZcV7XSxsqZC68h+/0bHt8C+V//0nGXAwD14vuXEAReVYvwlB31GAvv1Qc3LYZP F84vhOolOm1X4WEa89wA7K82btUqPdu+afXK+IPQw/4M6Bq0BU9egv4AybB3hn6FOK81tVy5E 8quv27Dv7aIn4w+MYTQw== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220530_054406_573266_689BD394 X-CRM114-Status: GOOD ( 14.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 30, 2022 at 11:33 AM Jani Nikula wrote: > > That is, for EDID. Makes you wonder about all the other packed structs > with enum members across the kernel. It is not the 'enum' that is special here, it's the 'union' having unpacked members, and the same thing happens when you have nested structs: both the inner and the outer aggregate need to be packed, either with __packed at the end, or on each individual member that is not fully aligned to max(sizeof(member), 4)). I think in general, most __packed annotations we have in the kernel are completely pointless because they do not change the structure layout on any architecture but instead just make member access slower on architectures that lack unaligned load/store instructions. There have definitely been other cases though where a __packed annotation is not needed on any sane architecture but is needed for OABI ARM. Overall I'm not that worried because the only machines running OABI kernels would be on really old hardware that runs a limited set of driver code. A completely different matter are the extraneous __packed annotations that lead to possible problems when accessed through a misaligned pointer. We ignore -Waddress-of-packed-member and -Wcast-align in the kernel, so these never get caught at build time, but we have seen bugs from gcc making incorrect assumptions about alignment even on architectures that have unaligned load/store instructions. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel