From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753003AbcAVKEV (ORCPT ); Fri, 22 Jan 2016 05:04:21 -0500 Received: from mga04.intel.com ([192.55.52.120]:35066 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752906AbcAVKEL (ORCPT ); Fri, 22 Jan 2016 05:04:11 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,330,1449561600"; d="scan'208";a="895985525" Message-ID: <1453457080.2521.179.camel@linux.intel.com> Subject: Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel From: Andy Shevchenko To: =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= , Andy Shevchenko Cc: Julian Margetson , Tejun Heo , linux-ide@vger.kernel.org, "linux-kernel@vger.kernel.org" Date: Fri, 22 Jan 2016 12:04:40 +0200 In-Reply-To: References: <1450221935-6034-1-git-send-email-mans@mansr.com> <1450724880.30729.250.camel@linux.intel.com> <1450731289.30729.282.camel@linux.intel.com> <1450781890.30729.298.camel@linux.intel.com> <1452159294.30729.405.camel@linux.intel.com> <1452243464.30729.430.camel@linux.intel.com> <1453317808.2521.135.camel@linux.intel.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2016-01-20 at 20:07 +0000, Måns Rullgård wrote: > Andy Shevchenko writes: > > > > > > > One comment still regarding to lli types. We can avoid > > > > > > warnings by > > > > > > using (__force u32) in macros. > > > > > > > > > > But that won't give the benefits of having the types checked. > > > > > > > > You mean if we access the lli->field directly? I didn't quite > > > > get what > > > > use case you are keeping in mind. > > > > > > Yes, accessing any of those fields directly with my patch gives a > > > sparse > > > warning.  It's situations like these those checks are intended > > > for. > > > Defeating them seems foolish to me. > > > > Otherwise it makes that struct looks ugly. > > Why not union, though it still ugly, but less. > > What's so ugly about it?  IMO data should be declared as the type it > actually is, and here we have fields that might have a different byte > order from the host CPU.  The __be32 and __le32 types were invented > to > make such situations clear and allow automatic (sparse) > checking.  I'd > say the price of one small typedef is well worth it.  The actual code > is > not impacted since it must use the accessor macros anyhow. Okay, let's move with current state. I have few style minors and a question. So, in type definitions can we use __dw32 instead of dw_u32? In DWC_DEFAULT_CTLLO() can we do tab indentation for \ ? Now the question: who do you prefer to submit the series (dw_dmac)? Me or you? In case you would like to do it (what I see in your dwc-sata branch today): Acked-by: Andy Shevchenko -- Andy Shevchenko Intel Finland Oy