On Tue, 2018-11-20 at 21:42 +0100, Stefan Agner wrote: > On 20.11.2018 20:13, Trent Piepho wrote: > > > > On IMX7d, there are significant blocks of 00s in the config space, and > > all 0xff at 0xb50 on up. > > > > I.e., significant portions are empty, in the middle of the config > > space, not just at the end. > > > > But they can be read without problem. > > > > Perhaps imx6q aborts on a read of an unimplemented address instead of > > returning zeros like imx7d. In that case it really needs something > > more complex to prevent abort than just a length. > > Yeah it seems those SoCs behave differently. > > Describing a register set with holes will get complicated, I guess it > would ask for a regmap... > > > > > It also seems to me that this doesn't need to be in the internal pci > > config access functions. The driver shouldn't be reading registers > > that don't exist anyway. It's really about trying to fix sysfs access > > to registers that don't exist. So maybe it should be done there. > > That was my first approach, see: https://lkml.org/lkml/2018/11/14/716 Yes, but that just used the pci device id which applies to every IMX design. It's also not totally correct, as it seems real registers after 0x200 do work on imx6, and that would prevent access to them. Like you say, it could use a regmap. Seems kinda overkill to me though. I wonder if regmap based caching of register to avoid RMW cycles would be generally useful? I know the enable and mask registers are/were cached in the driver (irq_state[]).
