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

[Måns Rullgård]

Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> writes:

> On Wed, 2016-01-20 at 20:07 +0000, Måns Rullgård wrote:
>> Andy Shevchenko <andy.shevchenko@xxxxxxxxx> 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?

Sure, no problem.

> In DWC_DEFAULT_CTLLO() can we do tab indentation for \ ?

Is there a wrong indentation somewhere?  I don't see it.

> 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@xxxxxxxxxxxxxxx>

I'll fix the above, give your changes a review, and add my sign-off
before sending the series, today or during the weekend.

-- 
Måns Rullgård