On Mon, May 18, 2020 at 05:48:34PM +0300, Andy Shevchenko wrote: > On Mon, May 18, 2020 at 04:43:06PM +0300, Serge Semin wrote: > > On Mon, May 18, 2020 at 04:25:20PM +0300, Andy Shevchenko wrote: > > > On Mon, May 18, 2020 at 3:53 PM Serge Semin > > > <Sergey.Semin@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Mon, May 18, 2020 at 02:03:43PM +0300, Andy Shevchenko wrote: > > > > > On Sat, May 16, 2020 at 11:01:33PM +0300, Serge Semin wrote: > > > > > > On Fri, May 15, 2020 at 05:38:42PM +0300, Andy Shevchenko wrote: > > > > > > > On Fri, May 15, 2020 at 01:47:49PM +0300, Serge Semin wrote: > > ... > > > > > > > It's not like anyone cared about padding in this structure in the first place) > > > > > > > > > > I think I have been caring (to some extend). > > > > > > > > Well, If you have then instead of asking to rearrange just two members (which > > > > by the way finely grouped by the Tx-Rx affiliation) why not sending a > > > > patch, which would refactor the whole structure so to be optimal for the x64 > > > > platforms? I don't really see why this gets very important for you seeing > > > > Mark is Ok with this. My current commit follows the common driver design > > > > including the DW SSI data members grouping. On the second thought I'll leave > > > > it as is then. > > > > > > Again same issue here. What is really easy to do for you here, will > > > become a burden and additional churn to anybody else. > > > So, why not to minimize it in the first place? Same with comma in > > > another patch. Sorry, I really don't get it. > > > > If comma is more or less understandable (though adding it is absolutely > > redundant there and doesn't worth even a bit of time spending for the > > discussion), here you consider the patch from padding point of view. > > The driver developer didn't care about it, but did care about grouping the > > members in a corresponding way. The padding burden will be there anyway and > > should be fixed for the whole structure in an additional patch. Until then > > the way of grouping should be preserved. > > Like you said, we spent already much more time than that simple change can be > satisfied. And like you said, "deleloper ... did care about groupping members > in a corresponding way". So, if we look at this in the original code, my > suggestion, besides padding benefit, is consistent with existing pattern in > that data structure. What pattern do you mean? As I see it, my implementation is consistent with current structure structure, while yours is not. -Sergey > > Note, I agree on extern keyword change can be postponed (it was in the original > code), but here you introduce a new code... > > -- > With Best Regards, > Andy Shevchenko > >
