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 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 08E3BC433F5 for ; Mon, 30 May 2022 14:40:05 +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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JEhf9yeZd4pS2tAWInjcMuRSOygNhI5I2IaK6vF4VK0=; b=ka4ttOtW42jmM3 oGRIRVt1RSSnBjpve0OF/FxPRRy1XrOep+Kk5VPvRuLuPRvbasd5Z6nXOehaeBuCditPUAUmSmuCO 0HW142TM4WU35h94Wn+T0ohRe+GzcUtnUwDn0vBarMo+64/y3pEfGVtIu8U7MBOSIIb/jDHij1J0G bE+CrQSl5G0jj2QqtdjIHKrMGM2qNlEpmQZiXmyVLjHVZhoV4LzyW7ATRC6BkqnApd3R7NzgTb6Pc FJQBwhc2p/a0O8q0J3j/cGUkmCTZMchIDSq72cgdyoSRRrGYHw31U1Pb84Ig3e2dAdETOjAIgC3Gz /R3UL3fBlGvHjkpogMYA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nvgXN-007I3H-2s; Mon, 30 May 2022 14:38:30 +0000 Received: from mga07.intel.com ([134.134.136.100]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nvg4E-00744O-Mb for linux-arm-kernel@lists.infradead.org; Mon, 30 May 2022 14:08:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653919702; x=1685455702; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=4UKqK9LTE8r/QhEwT/GHcr6rLTi06cgfbkbko9SrhVU=; b=jVTmPHA3mMA8nnCAEqVCSaZev9Evv52Pv0mS20fUUgBhg+a3U7Cc0OWq A1AodWzye2eev2sFejWDuU+3j0RE+K0PpkK4NbJLPQB1mvplvUsaI5Pkq VOQhPTPZ5jb8MetktfypqG7/nIIGytT3W5KngyUcblQUgF4I/Pzv4pLcy KJTGrOmjejQLQQgN6d4kdrdC4PS5LXHpEFhtTwBvFUYmCIqYY/q7x5cNF O0iq7QBOXuHs415qq+XSsPWI1gHQBO1LLGK9f2YsIB+Ee0d8keWk00zYd mZdsjjttyVod49Lzzy527hj9aZZWeqyrZrWikPfHhMZQpW2n6i8z9Bajs A==; X-IronPort-AV: E=McAfee;i="6400,9594,10363"; a="338047567" X-IronPort-AV: E=Sophos;i="5.91,263,1647327600"; d="scan'208";a="338047567" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.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 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220530_070822_868642_013DF5B4 X-CRM114-Status: GOOD ( 20.06 ) 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, 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 2ED7DC433F5 for ; Mon, 30 May 2022 14:08:22 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 402F810ECF0; Mon, 30 May 2022 14:08:21 +0000 (UTC) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9A00110ECF0 for ; Mon, 30 May 2022 14:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653919700; x=1685455700; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=4UKqK9LTE8r/QhEwT/GHcr6rLTi06cgfbkbko9SrhVU=; b=a02bX00PkLEw1zZo8rJ44HnsmPMSlgxEqFZA66rNstSySsZ3NMDdy2EE uKf2xGofMe8KL1+QYa0lJLkFcIJXKXdEoFmIDVL7R6K6zUjnjjXaHCxYN qRTHy9n464cRhnnJX4iUw6kk5myDzQ44rmOtyMcfIVYIjuyn4VWD8qq/2 Nv41L25/Msqf9hL9+Xj8e6MCCdW/D8qD3dBrsVDBkJoi/Zx/Ez9nSMzku 0bcMY7/XghUU2YFByYBELGJOztDj5Ta9w7o6RgHwKn0ROp2KSzmTzNEQm 5bUEA23Sj45qXQnufsmPBY9yuxwhDP6xjnBu9XqgWdlJoHSVMVvLf5PZD w==; X-IronPort-AV: E=McAfee;i="6400,9594,10363"; a="257072119" X-IronPort-AV: E=Sophos;i="5.91,263,1647327600"; d="scan'208";a="257072119" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.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 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 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , Arnd Bergmann , David Airlie , Viresh Kumar , Russell King , Linux Kernel Mailing List , Julia Lawall , Linus Torvalds , SoC Team , dri-devel , Thomas Zimmermann , Shiraz Hashim , Sudip Mukherjee Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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