Message ID | 45ec4924e0b34a3d9124e2db06af75b4@tpw09926dag18e.domain1.systemhost.net |
---|---|
Headers | show |
Series | Invert Endian bit in SPARCv9 MMU TTE | expand |
On 8/7/19 10:23 AM, tony.nguyen@bt.com wrote: [...] > v3: > - Like v1, the entire TCGMemOp enum is now MemOp. > - MemOp target dependant attributes are conditional upon NEED_CPU_H > > v4: > - Added Paolo Bonzini as include/exec/memop.h maintainer > > v5: > - Improved commit messages to clarify how interface to access > MemoryRegion will be converted from "unsigned size" to "MemOp op". > - Moved cpu_transaction_failed() MemOp conversion from patch #11 to #9 > to make review easier. > > v6: > - Improved commit messages. > - Include as patch #1 an earlier posted TARGET_ALIGNED_ONLY configure patch. > - Typeless macro SIZE_MEMOP is now inline. > - size_memop now includes CONFIG_DEBUG_TCG code. > - size_memop now also encodes endianness via MO_TE. > - Reverted size_memop operand "unsigned long" back to "unsigned". > - Second pass of size_memop to replace no-op place holder with MO_{8|16|32|64}. > - Delay memory_region_dispatch_{read,write} operand conversion until no-op > size_memop is implemented so we have proper typing at all points in between. > - Fixed bug where not all memory_region_dispatch_{read,write} callers where > encoding endianness into the MemOp operand, see patch #20. > - Fixed bug where not all memory_region_dispatch_{read,write} callers were > collapsing their byte swap into adjust_endianness, see patch #20 and #22. > - Split byte swap collapsing patch (v5 #11) into #21 and #22. > - Corrected non-common *-common-obj to *-obj. > - Replaced enum device_endian with MemOp to simplify endianness checks. A > straight forward sed but touched *alot* of files. See patch #16 and #17. > - Deleted enum device_endian. > - Deleted DEVICE_HOST_ENDIAN definition. > - Generalized the description of introduced MemTxAttrs attribute byte_swap. I'm confused I think I already reviewed various patches of your previous series but don't see my Reviewed-by tags.
On 8/7/19 8:37 PM, Philippe Mathieu-Daudé wrote:
> I'm confused I think I already reviewed various patches of your previous
?> series but don't see my Reviewed-by tags.?
Apologies Philippe! I am the confused one here =/
Will append.
Thank you very much for the reviews and qemu-devel newbie tips so far. I have felt very welcome.
Tony
On 8/7/19 2:41 PM, tony.nguyen@bt.com wrote: > On 8/7/19 8:37 PM, Philippe Mathieu-Daudé wrote: > >> I'm confused I think I already reviewed various patches of your previous > > series but don't see my Reviewed-by tags.> > Apologies Philippe! I am the confused one here =/ > > Will append. > > Thank you very much for the reviews and qemu-devel newbie tips so far. I > have felt very welcome. Well for a newbie you did an impressive series! The 'Reviewed-by' or 'Tested-by' tags help the maintainers to process patches. Since reviewing a series is time-consuming, if you iterate over a series without changing some patchs, you should collect and amend the tags the reviewers gave you, this way it helps them keep track of patches reviewed and patches waiting for review. In my case I find it very confuse when I look at a patch I already gave my R-b tag and the tag is not here, I re-review the patch looking for differences. Often a reviewer asks for easy changes, and uses "with this changes: R-b". If you addresses his comments you can then add his tag in the next version. If you split a reviewed patch in various, it is also OK to keep the tags in all the splitted patches. Regards, Phil.