Messages in this thread | | | Subject | Re: About commit "io: change inX() to have their own IO barrier overrides" | From | Sinan Kaya <> | Date | Mon, 2 Mar 2020 11:44:50 -0500 |
| |
On 3/2/2020 7:35 AM, John Garry wrote: > Hi Sinan, > > Thanks for getting back to me. > >> On 2/28/2020 4:52 AM, John Garry wrote: >>> About the commit in the $subject 87fe2d543f81, would there be any >>> specific reason why the logic pio versions of these functions did not >>> get the same treatment > > In fact, your changes and the logic PIO changes went in at the same time. > > or should not? I'm talking about lib/logic_pio.c
I think your change missed "cross-architecture" category.
> > #define BUILD_LOGIC_IO(bw, type) > type logic_in##bw(unsigned long addr) > { > type ret = (type)~0; > if (addr < MMIO_UPPER_LIMIT) { > ret = read##bw(PCI_IOBASE + addr); *** > } else if (addr >= MMIO_UPPER_LIMIT && addr < IO_SPACE_LIMIT) { > struct logic_pio_hwaddr *entry = find_io_range(addr); > > if (entry) > ret = entry->ops->in(entry->hostdata, > addr, sizeof(type)); > else > WARN_ON_ONCE(1); > } > return ret; > } > >> How is the behavior on different architectures? > > So today only ARM64 uses it for this relevant code, above. But maybe > others in future will want to use it - any arch without native IO port > access is a candidate.
I'm looking at Arnd here for help.
> >> >> As long as the expectations are set, I see no reason why it shouldn't >> but, I'll let Arnd comment on it too. > > ok, so it looks reasonable consider replicating your change for ***, above.
Arnd is the maintainer here. We should consult first. I believe there is also a linux-arch mailing list. Going there with this question makes sense IMO.
> > Thanks, > John
| |