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 EC92AC433F5 for ; Mon, 30 May 2022 14:44:44 +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=GngTKLOWswgtqbFoy7t6DI+zvJ3ZFtqtW3WDeuRQA0E=; b=Sk8bf3MmUNE6gD XGGALKC8Alrqc+bf3yFPjzkr+b5P92/+0QUEZn87p36iKaZLyhrAqsgJto0TIACH11SYdyJWBTOil o4kaLb9U0CUTs0c9BysCJrobFvMzKxNfKhoep+No6+etXwqLiJr719jlLfHXZmCiOZbo3xLCsX3kz gtGHysDeBK19axy4GE+oEgi+jP6wpzJajAu0TBsmtg3qEnUkpNKxQsrADVsb6bHCIFTEpJDbEMF4v BUViVfdEoqdQqs6zSL/mykGluDLGHFJkB88Ot21Lq5UOL+gQKiiv/xlWYXnu4MppGjhoKWrqKBIrR ZU9AthPHySYteF1k1PfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nvgbv-007K9j-12; Mon, 30 May 2022 14:43:11 +0000 Received: from mout.kundenserver.de ([212.227.126.135]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nvgMK-007CYs-W7 for linux-arm-kernel@lists.infradead.org; Mon, 30 May 2022 14:27:06 +0000 Received: from mail-yb1-f173.google.com ([209.85.219.173]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MjgfT-1nYDZG2dfn-00lFq6 for ; Mon, 30 May 2022 16:27:01 +0200 Received: by mail-yb1-f173.google.com with SMTP id v106so12309553ybi.0 for ; Mon, 30 May 2022 07:27:01 -0700 (PDT) X-Gm-Message-State: AOAM532ZwTTTbGhaSuHg8L0soFSvBi4QfFljMrQDTuw4V4M+/cgMrBl+ 6CTeH53ZzaniCU6ae0hwV9xkQAU4GMDyCDiy8+M= X-Google-Smtp-Source: ABdhPJx5T8sAy2mpNYpXUMEEXXq3paGLe37RJlBPWUL37w/VrSqmqA+dX26yPRFsA+fHHAhbaULTIG1qF0gAbTdb1Dw= X-Received: by 2002:a25:4f0a:0:b0:64f:6a76:3d8f with SMTP id d10-20020a254f0a000000b0064f6a763d8fmr43544693ybb.134.1653920820404; Mon, 30 May 2022 07:27:00 -0700 (PDT) MIME-Version: 1.0 References: <87a6aztli2.fsf@intel.com> <877d63tleq.fsf@intel.com> <87czfvrwsv.fsf@intel.com> <874k17ru44.fsf@intel.com> In-Reply-To: <874k17ru44.fsf@intel.com> From: Arnd Bergmann Date: Mon, 30 May 2022 16:26:43 +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: Arnd Bergmann , Linus Torvalds , 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 , Julia Lawall X-Provags-ID: V03:K1:V9tnALmTDF2ea3FlgtG/hL3ZB5KNbJjbm3vJuDM2GDLOKyTtTC8 B5G0lqvwotWKv7xDMAu/dUrIsNvYYhIXwaNux2jvJjtfUJx4jCk8vlL4fHJ09mbdKY4cS/a rRh+dRbqTTD5OH4/77zsj/xPdZi2vZtPmxHh53y2cs3ag6i0yxlOOwJgUYs6QwkzTrf0Y0Z VndT3nmMgXYlYebAA0BYg== X-UI-Out-Filterresults: notjunk:1;V03:K0:nvAEyFCiOzo=:vkDAb1AuynC30AEpL3Skyk fU0jh5IZaA3ahKEr2zIn7dHJIBt4V2muOEIkenhSiM2GX4/DwvLnPmN/YX7RVGsZN3Lxd16pc 7njCRXp2S6nzPzoYfvyIMWyBuIsvfzLE9BjxqL7L720A4RHobeCc89wcONNdSBL2NMVqQMlFX ve8DneR5zs+v/r+i7+33Cy3H2+1tGYex0DMttTduYNi5Q8K6ImNjE2CTtYcHzEi9gHZ6I+3+E mBLBIwPXkpPGMFLlcnNNPktIUfwvh9WMJTpbO6mf0m9e3Fr9dyUOq30atttu1sBSYf3eHP4Dx rObbQ4klen990v1qZ20l6XiJFDTEYsUCgOeonVN6ECc3ojv9+VU+vNQWgTerm2sv/OEh0W3lr cE/Cd9bOTKITMARNchMEpucfRyq9MItX4Xk8JZvDii+1rC510KI4XGCh53Z4D1NE5Hlr3woqN +JFIHW+9b61bAqhaEhKUZXhK68hGeAajbzRMgCjTb2SzzhUCIQdf4L/tZlqyeGy+3IUT715Jn kS4m/gwsXioqux50bGyR8ghjKWCBfuDXM+j55+auw9s05F3aXLXzqix8ahP5XgG9NnrPxSHzW +N6fFZejMBzTutB9fwCkGL2OJP1hjjfWqWOo6baZbzFhoGWACrryjSYOYdhmLQlun7UWE5/7B d/EMAaScUtw7xKxMQZy786YI0I6ldFhdFREt+zayuZxZpv+o15LNw4GY1BVOojY4QV+Iru0Av E5fHx8jk1+OuKT2IF9T0ho+Mu9ZIbyCTtbz/P+foO30OMSWng36myUpjDKn3Wi+NPqlPRZXD3 tC7HL3tOL+Lsg5ydi4F6AljHeef77Wl+sEIyxKZd79499A1UIpkwJPVhxM5Gf8KYv0NbKl6T6 tJamsJIyzQ4wulzNFkIpzjISLoee+Q3u2knbAxUxY= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220530_072705_394892_A7BD0E7C X-CRM114-Status: GOOD ( 22.57 ) 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 4:08 PM Jani Nikula wrote: > On Mon, 30 May 2022, Arnd Bergmann wrote: > > struct my_driver_priv { > > struct device dev; > > u8 causes_misalignment; > > spinlock_t lock; > > atomic_t counter; > > } __packed; /* this annotation is harmful because it breaks the atomics */ > > I wonder if this is something that could be caught with coccinelle. Or > sparse. Are there any cases where this combo is necessary? (I can't > think of any, but it's a low bar. ;) > > Cc: Julia. I think one would first have to make a list of data types that are not meant to be in a packed structure. It could be a good start to search for any packed aggregates with a pointer, atomic_t or spinlock_t in them, but there are of course many more types that you won't find in hardware structures. > > or if the annotation does not change the layout like > > > > struct my_dma_descriptor { > > __le64 address; > > __le64 length; > > } __packed; /* does not change layout but makes access slow on some > > architectures */ > > Why is this the case, though? I'd imagine the compiler could figure this > out. When you annotate the entire structure as __packed without an extra __aligned() annotation, the compiler has to assume that the structure itself is unaligned as well. On many of the older architectures, this will result in accessing the values one byte at a time. Marking the structure as "__packed __aligned(8)" instead would be harmless. When I have a structure with a few misaligned members, I generally prefer to only annotate the members that are not naturally aligned, but this approach is not very common. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel