linux-kernel - Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Jan 2016 12:04:40 +0200
From:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:	Måns Rullgård <mans@...sr.com>,
	Andy Shevchenko <andy.shevchenko@...il.com>
Cc:	Julian Margetson <runaway@...dw.ms>, Tejun Heo <tj@...nel.org>,
	linux-ide@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find
 dma channel

On Wed, 2016-01-20 at 20:07 +0000, Måns Rullgård wrote:
> Andy Shevchenko <andy.shevchenko@...il.com> 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 <andriy.shevchenko@...ux.intel.com>
-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy