Re: [PATCH v2 08/10] dp8393x: don't force 32-bit register access

[Finn Thain <fthain@linux-m68k.org>]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Thu, 1 Jul 2021, Philippe Mathieu-Daudé wrote:

> On 6/25/21 8:53 AM, Mark Cave-Ayland wrote:
> > Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" assumed that 
> > all accesses to the registers were 32-bit 

No, that assumption was not made there. Just take a look at my commits in 
Linux that make 16-bit accesses. If commit 3fe9a838ec worked by accident, 
it probably just reflects my inadequate knowledge of QEMU internals.

> > but this is actually not the case. The access size is determined by 
> > the CPU instruction used and not the number of physical address lines.
> > 

I think that's an over-simplification (in the context of commit 
3fe9a838ec).

> > The big_endian workaround applied to the register read/writes was 
> > actually caused by forcing the access size to 32-bit when the guest OS 
> > was using a 16-bit access. Since the registers are 16-bit then we can 
> > simply set .impl.min_access to 2 and then the memory API will 
> > automatically do the right thing for both 16-bit accesses used by 
> > Linux and 32-bit accesses used by the MacOS toolbox ROM.
> 
> Hmm I'm not sure. This sounds to me like the "QEMU doesn't model busses 
> so we end using kludge to hide bugs" pattern. Can you provide a QTest 
> (ideally) or a "-trace memory_region_ops_\*" log of your firmware 
> accessing the dp8393x please?
> 

The DP83932 chip is highly configurable, so I'm not sure that the 
behaviour of any given firmware would resolve the question.

Anyway, as far as the DP83932 hardware is concerned, the behaviour of the 
upper 16-bits of the data bus depends on the configuration programmed into 
the DP83932 registers, and whether the chip is accessed as a slave or 
performing DMA as a master.