Hi, On 04/09/15 16:11, Pavel Fedin wrote: > Hello! > >> Isn't the len parameter redundant here? I see that you don't initialize >> mmio.len (which is a bit scary, btw), so can't you just use that field? > > This was because of split below. I did not know about call_range_handler(), and now i will redo > this. > >> That (and other parts of this patch) sneak in some endianness handling, >> which I'd like to be mentioned in the commit message, but preferably be >> in a separate patch. The commit message here talks only about refactoring. > > These come from mmio_data_read() and mmio_data_write() in original vgic_attr_regs_access(). > These inlines cannot be used with arbitrary data length, so i opened them up (they contain > endianness conversion plus masking which isn't used in our case) and moved endianness conversion to > load/store part. > If i make this a separate patch, it will be two lines patch. Does it worth that? In the next respin > i'd better add this explanation to commit message. Would it be OK? >From a review (and later bisecting) point of view separate patches would be better. Ideally the refactoring does not introduce any change except code moving around. Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
