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 smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A4D22C433FE for ; Mon, 30 May 2022 14:08:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) id 72521C3411A; Mon, 30 May 2022 14:08:22 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.kernel.org (Postfix) with ESMTPS id 17EE2C385B8; Mon, 30 May 2022 14:08:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.kernel.org 17EE2C385B8 Authentication-Results: smtp.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653919701; x=1685455701; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=4UKqK9LTE8r/QhEwT/GHcr6rLTi06cgfbkbko9SrhVU=; b=YRK72tNmw4KjW1PbCk7Yzyz/WXo54DPhJDIy6zZ3/8qAxFl0x4Ny09qM Qk0CYmcU0ia9rvwahkS/Q5AaJnUc14Z3bL7Pf+tTnFjKC1oGt4WUR0PIg u6G9TtBJ/0SmrLjQZr04kWQhd56eZG/lAkAuQleWnk3Fk/wNYZJuIXWWy IGc8YjZRj7nAivuOp3IyVt4MX5457uP7axFqJh/rOq0KXV2roT/OhcoIO qLlYbV55YOuhLIIlowUFub3XIVm9+tKzf6oYIQkbLK66nb5J24cp2d/F8 +I4x1YaDgehHB/0zybB9rYAjTLPuz6QKmAfGzkSTeUugwwkpgP5rvscsz A==; X-IronPort-AV: E=McAfee;i="6400,9594,10363"; a="272581014" X-IronPort-AV: E=Sophos;i="5.91,263,1647327600"; d="scan'208";a="272581014" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 May 2022 07:08:20 -0700 X-IronPort-AV: E=Sophos;i="5.91,263,1647327600"; d="scan'208";a="605206585" Received: from jkuna-mobl.ger.corp.intel.com (HELO localhost) ([10.249.150.228]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 May 2022 07:08:14 -0700 From: Jani Nikula To: Arnd Bergmann List-Id: Cc: Arnd Bergmann , Linus Torvalds , Sudip Mukherjee , Russell King , Viresh Kumar , Shiraz Hashim , Ville =?utf-8?B?U3lyasOkbMOk?= , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , dri-devel , Linux Kernel Mailing List , Linux ARM , SoC Team , Julia Lawall Subject: Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers") In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <87a6aztli2.fsf@intel.com> <877d63tleq.fsf@intel.com> <87czfvrwsv.fsf@intel.com> Date: Mon, 30 May 2022 17:08:11 +0300 Message-ID: <874k17ru44.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain On Mon, 30 May 2022, Arnd Bergmann wrote: > On Mon, May 30, 2022 at 3:10 PM Jani Nikula wrote: >> > >> > 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 >> >> Please explain. >> >> They are used quite a bit for parsing blob data, or >> serialization/deserialization, like in the EDID case at hand. Try >> removing __attribute__((packed)) from include/drm/drm_edid.h and see the >> sizeof(struct edid) on any architecture. > > The annotations for edid are completely correct and necessary. However > other driver authors just slap __packed annotations on any structure > even if the layout is not fixed at all like: Right. Thanks for the examples. > 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. > 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. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center