On Wed, Feb 13, 2019 at 1:36 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Wed, 13 Feb 2019 at 18:54, Thomas Huth <th...@redhat.com> wrote: > > > > On 2019-02-13 18:14, Peter Maydell wrote: > > > On Wed, 13 Feb 2019 at 00:13, Alistair Francis <alistai...@gmail.com> > > > wrote: > > >> I know the other RISC-V files don't do it, but this should go in the > > >> hw/gpio directory instead of hw/riscv. > > > > > > It might be nice to move those existing riscv devices into > > > their proper places at some point: should be a fairly easy > > > cleanup patch if somebody wants to take it on. (Advice > > > on what should live where available on request.) > > > > If devices only work on riscv, they should IMHO stay in hw/riscv/. I > > think hw/gpio/ and friends should primarily be used if a device is > > shared between architectures. If they stay in hw/riscv/ it is way easier > > to match the devices with wildcards in the MAINTAINERS file. Just my > > 0.02 € only, of course. > > This is not the way we generally arrange the source tree, > at least not the parts I'm familiar with. The rule of > thumb I use is that devices of type X go in hw/X, and > hw/$ARCH is only for board models and SoC container objects. > I think the model for this is the Linux kernel, which > splits drivers for devices into directories by device > family, rather than putting them all in arch/whatever. > A split that puts all the architecture-specific device > models in hw/$ARCH has the significant disadvantage that > it would put a huge number of files in hw/arm ...
That is how I understood it as well. I think some of the current files in hw/riscv/ could be moved, but they are somewhat border line and we don't have many files yet so I wasn't bothering yet. This GPIO device doesn't have to be RISC-V specific so it makes sense to put it under hw/gpio. The maintainers file will need to be updated though. Alistair > > (More generally, I don't think the exact way we split > the source files between directories matters much, but > I do think it helps if we try to be consistent about it.) > > thanks > -- PMM
