Hi everyone. Will be grateful for any pointers .. Is it that the __iomem__ attribute merely a legacy thing now, with it being a no-op? In other words, vanilla-dereferencing will work in both userspace and kernel-space, with the cpu-system-agent taking care of routing the transaction to the mapped device? On Sat, Nov 16, 2024 at 3:12 PM Ajay Garg <ajaygargnsit@xxxxxxxxx> wrote: > > Hi everyone. > > First, setting up context; kindly correct me if I am wrong :) > > In kernel-space : > ----------------------- > > * > We use ioremap to map a BAR-area physical-memory into kernel's > virtual-address space. > > * > We then need to use *special* accessor-functions (ioread/iowrite and > friends) to ensure that the I/O is propagated through fine via path > kernel-virtual-memory <=> BAR-physical-memory <=> device > > > In user-space : > ----------------------- > > * > We mmap() a sysfs-file, which causes the kernel to map a userspace VMA > to the same BAR-area physical-memory (using remap_pfn_range() or > equivalent). > > * > We then use *vanilla* dereferencing to read/write via path > userspace-VMA <=> BAR-physical-memory <=> device. > > > Now, my queries are regarding the usage of *special* > accessor-functions in kernel-mode, versus *vanilla* dereferencing in > user-mode. > > a) > Firstly, is my assertion true? :) > > b) > If yes, then how is the path userspace-VMA <=> BAR-physical-memory <=> > device possible via *vanilla* dereferencing in user-mode? > > > Will be grateful for insights .. > > Thanks and Regards, > Ajay
