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? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
