On 2016-07-04 07:49, David Kiarie wrote: >>>>> +/* FIXME: something might go wrong if System Software writes in chunks >>>>> + * of one byte but linux writes in chunks of 4 bytes so currently it >>>>> + * works correctly with linux but will definitely be busted if software >>>>> + * reads/writes 8 bytes >>>> >>>> What does the spec tell us about non-dword accesses? If they aren't >>>> allowed, filter them out completely at the beginning. >>> >>> Non-dword accesses are allowed. Spec 2.62 >>> >>> ".... Accesses must be aligned to the size of the access and the size >>> in bytes must be a power >>> of two. Software may use accesses as small as one byte..... " >>> >>> Linux uses dword accesses though but even in this case a change in the >>> order of access whereby the high part of the register is accessed >>> first then the lower accessed could cause a problem (??) >> >> I do not get yet what makes it tricky to support all allowed access >> sizes. You are just missing byte access, and that will easy to add once >> the size dispatching is done in a single function like suggested below. > > It is tricky because I need to ready some values that may span across > 1,2,4-byte boundaries and I don't have a way to tell that software is > done writing. The current logic is based on the assumption that > software writes the low bytes first which is mostly the case but might > not always be the case.
According to the spec, software is allowed to read or write any byte, word, dword and qword, provided it is naturally aligned. Just model that access, nothing more. If a high-word/byte access triggers some side effect, than that is what it does (and probably a reason why Linux avoids it). Jan
signature.asc
Description: OpenPGP digital signature