Received: by 10.213.65.68 with SMTP id h4csp627753imn; Tue, 13 Mar 2018 15:35:24 -0700 (PDT) X-Google-Smtp-Source: AG47ELv6P02IaJGjRycMEZVqw0aQwdVurdtk7AHWpEAY/D3bI+W7gqsngHO7v5bEyd6Tjx3NfNV1 X-Received: by 2002:a17:902:2cc1:: with SMTP id n59-v6mr1930112plb.215.1520980524147; Tue, 13 Mar 2018 15:35:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520980524; cv=none; d=google.com; s=arc-20160816; b=xLZbviIgAM7hvUxnAB3rSa2hPOp3M5w2L/+TwJE71AUbm5lqZQ4+nLCDYNZM/pcQIZ NbqbDr5qFDk4LSqCNdHdBrkh2eGSOPXNccMDS3Jf0KG+lAlcV25qo0Bzop6fhDsE5tPf lkNIvD+ZIeY/BptBQnzs+Zt/fM0Z0BS/9mt/v5YZqEvSxwRao5McnZ55pXO2EtNchUO4 llae6KnnLLY/aQJdeJ1f0AyzFKdqGSoHFWBKCpWgw0Am+NrhnZUAm+a7kW9rB82B7rnT 3sb5cD8HG+zHj7cS2DYBB09gEhNRDSVY0eJIv6EG/oF0I3x3GKMYkT2bPVWkvvDF56Km vFLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:reply-to:references:cc:to:subject :dkim-signature:arc-authentication-results; bh=sHwQuHXv/KQ1O69aCOhzKINATyVPAOdeix9Y7pd5UvM=; b=Xs5/4YeFDGw2LR0PuOsE3e4TYpdCEfmwxuJghVsT94iDZ/4YbAMBRntbptfbfZm9xH aPE2TV60g42djoxh/6He+E/VJZzKqMjUfBb2wxB3Ldta8yQrxyY4gek8pGSELJKsX7pv 775/n1ApbSYqrihTcIEn6hctxi4dvSUeQ7gOzCQQQQ4sHej/IMxed2rqO2gNUBISALxt 4PFWyzgCOLwNhugzqU3DM4jrD/2ia7ZlyJZiap5/qNE8042If5WsA2LFx1iaCYXAgoYJ +p1BmPIXeKaa7CjbAvHmQcK+tLLDcRB011S/0Vt+M6ST+HgUMBGYved1mLAzprsUfSbt oG/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=u6Nb26bn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l36-v6si843592plg.667.2018.03.13.15.35.10; Tue, 13 Mar 2018 15:35:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=u6Nb26bn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752991AbeCMWeQ (ORCPT + 99 others); Tue, 13 Mar 2018 18:34:16 -0400 Received: from galahad.ideasonboard.com ([185.26.127.97]:42403 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752209AbeCMWeO (ORCPT ); Tue, 13 Mar 2018 18:34:14 -0400 Received: from [192.168.43.222] (unknown [149.254.234.209]) by galahad.ideasonboard.com (Postfix) with ESMTPSA id 33D7C20BEA; Tue, 13 Mar 2018 23:32:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1520980322; bh=2ZVabEdesImWXIrGkgT6VHB1Whsn8zapoeyH3+3sEuw=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=u6Nb26bnKTP6TmP+CNugpOUQo4rmN+VcJmel1fG3dobuAoivqVOgT0D84r0GcVDkJ AWJpg7qw8CzOI/rif6sXY5fKls/9GlHHsrcvRVd5EztYzzDmB1heQqmsfuGr13tWS9 CdZ0p/N4jODPzA7l0p+zF+nSU53R81pxIwIhGc+Y= Subject: Re: [PATCH 02/11] media: vsp1: use kernel __packed for structures To: Kieran Bingham , David Laight , Laurent Pinchart , "linux-renesas-soc@vger.kernel.org" , "linux-media@vger.kernel.org" Cc: Mauro Carvalho Chehab , open list References: <767c4c9f6aa4799a58f0979b318208f1d3e27860.1520632434.git-series.kieran.bingham+renesas@ideasonboard.com> <8513c264-103f-94c8-cc46-972412d13da5@ideasonboard.com> <554b73e9ee2d43b19ac42ee380b7d160@AcuMS.aculab.com> <8ecfb374-e979-a54d-74d9-d65dfbb5c3ef@ideasonboard.com> Reply-To: kieran.bingham@ideasonboard.com From: Kieran Bingham Organization: Ideas on Board Message-ID: Date: Tue, 13 Mar 2018 23:34:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <8ecfb374-e979-a54d-74d9-d65dfbb5c3ef@ideasonboard.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, Just for reference here, I've posted a v2 of this patch now titled: [PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures which removes the attributes instead of modifying them. Thanks for the pointers! Regards Kieran On 13/03/18 15:03, Kieran Bingham wrote: > Hi David, > > On 13/03/18 13:38, David Laight wrote: >> From: Kieran Bingham [mailto:kieran.bingham+renesas@ideasonboard.com] >>> On 13/03/18 11:20, David Laight wrote: >>>> From: Kieran Bingham >>>>> Sent: 09 March 2018 22:04 >>>>> The kernel provides a __packed definition to abstract away from the >>>>> compiler specific attributes tag. >>>>> >>>>> Convert all packed structures in VSP1 to use it. >>>>> >>>>> Signed-off-by: Kieran Bingham >>>>> --- >>>>> drivers/media/platform/vsp1/vsp1_dl.c | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c >>>>> index 37e2c984fbf3..382e45c2054e 100644 >>>>> --- a/drivers/media/platform/vsp1/vsp1_dl.c >>>>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c >>>>> @@ -29,19 +29,19 @@ >>>>> struct vsp1_dl_header_list { >>>>> u32 num_bytes; >>>>> u32 addr; >>>>> -} __attribute__((__packed__)); >>>>> +} __packed; >>>>> >>>>> struct vsp1_dl_header { >>>>> u32 num_lists; >>>>> struct vsp1_dl_header_list lists[8]; >>>>> u32 next_header; >>>>> u32 flags; >>>>> -} __attribute__((__packed__)); >>>>> +} __packed; >>>>> >>>>> struct vsp1_dl_entry { >>>>> u32 addr; >>>>> u32 data; >>>>> -} __attribute__((__packed__)); >>>>> +} __packed; >>>> >>>> Do these structures ever actually appear in misaligned memory? >>>> If they don't then they shouldn't be marked 'packed'. >>> >>> I believe the declaration is to ensure that the struct definition is not altered >>> by the compiler as these structures specifically define the layout of how the >>> memory is read by the VSP1 hardware. >> >> The C language and ABI define structure layouts. >> >>> Certainly 2 u32's sequentially stored in a struct are unlikely to be moved or >>> rearranged by the compiler (though I believe it would be free to do so if it >>> chose without this attribute), but I think the declaration shows the intent of >>> the memory structure. >> >> The language requires the fields be in order and the ABI stops the compiler >> adding 'random' padding. >> >>> Isn't this a common approach throughout the kernel when dealing with hardware >>> defined memory structures ? >> >> Absolutely not. >> __packed tells the compiler that the structure might be on any address boundary. >> On many architectures this means the compiler must use byte accesses with shifts >> and ors for every access. >> The most a hardware defined structure will have is a compile-time assert >> that it is the correct size (to avoid silly errors from changes). > > > > Ok - interesting, I see what you're saying - and certainly don't want the > compiler to be performing byte accesses on the structures unnecessarily. > > I'm trying to distinguish the difference here. Is the single point that > __packed > > causes byte-access, where as > > __attribute__((__packed__)); > > does not? > > Looking at the GCC docs [0]: I see that __attribute__((__packed__)) tells the > compiler that the "structure or union is placed to minimize the memory required". > > However, the keil compiler docs[1] do certainly declare that __packed causes > byte alignment. > > I was confused/thrown off here by the Kernel defining __packed as > __attribute__((packed)) at [2]. > > Do __attribute__((packed)) and __attribute__((__packed__)) differ ? > > In which case, from what I've read so far I wish "__packed" was "__unaligned"... > > > [0] > https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-packed-type-attribute > > [1] http://www.keil.com/support/man/docs/armcc/armcc_chr1359124230195.htm > > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler-gcc.h?h=v4.16-rc5#n92 > > > Regards > > Kieran > > >> David >>