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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
