Hi Marc, > -----Original Message----- > From: Marc Zyngier [mailto:marc.zyngier@xxxxxxx] > Sent: Monday, May 22, 2017 10:41 AM > > On Mon, May 22 2017 at 7:12:39 am GMT, Laurentiu Tudor > <laurentiu.tudor@xxxxxxx> wrote: > > Hi Laurentiu, > > > Hi Marc, > > > >> -----Original Message----- > >> From: Marc Zyngier [mailto:marc.zyngier@xxxxxxx] > >> Sent: Saturday, May 20, 2017 9:43 AM > >> To: Matthias Brugger <matthias.bgg@xxxxxxxxx> > >> > >> On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger > >> <matthias.bgg@xxxxxxxxx> wrote: > >> > On 19/05/17 15:13, laurentiu.tudor@xxxxxxx wrote: > >> >> From: Stuart Yoder <stuart.yoder@xxxxxxx> > >> >> > >> >> Move the source files out of staging into their final locations: > >> >> -include files in drivers/staging/fsl-mc/include go to include/linux/fsl > >> >> -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip > >> > > >> > This driver has as compatible "arm,gic-v3-its". I wonder if this is > >> > correct and if it should be moved like this out of staging. > >> > >> This is no different from the way we handle *any* bus that uses the > >> GICv3 ITS as an MSI controller. Each bus provides its glue code that > >> latches onto the ITS node, and calls into the generic code. > >> > >> Now, when it comes to moving this out of staging, here is my concern: > >> There is mention of a userspace tool (restool) used to control the > >> HW. Where is this tool? Where is the user ABI documented? > > > > The tool is published here: > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > hub.com%2Fqoriq-open- > source%2Frestool&data=01%7C01%7Claurentiu.tudor%4 > > > 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92 > cd99c > > > 5c301635%7C0&sdata=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg > %3D&re > > served=0 > > > > There are two ways of configuring the mc-bus: > > - a static one, through a FDT based configuration file (we call it > > DPL), documented in the refman linked below, chapter 22. > > - a dynamic one, using this restool utility. > > Please note the usage of restool is optional. > > Optional or not, it still is a userspace ABI, and while I can see restool issuing ioctl > system calls to configure the HW, I cannot see the corresponding code in the > kernel tree. So how does it work? > If the syscall interface is not present in the mainline kernel, drop the reference > to it in the documentation. If it is there (and I obviously missed it), document it, > and get it reviewed. Our original plan was to first get the bus out of staging and after that submit the restool support ASAP (patches are done - so I'm thinking at few days timeframe). if this is not acceptable, I can drop the restool reference from the README and resubmit the patch series. We'll re-add the reference together with the restool support patches. > If there are associated DT bindings to the kernel code, they > must be documented (and reviewed) as part of the device-tree documentation, > and not in some obscure, hard to access document. There's only one binding involved and it's already accepted [1]. [snip] > > > > We're also working on publishing the docs on github so that they're > > more accessible. > > That'd be great, because the way the registration process is presented, I'd have > to agree to the Access Agreement *before* having a chance to read it. Not > going to happen... Sorry about that. Not much I can do. :-( [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt --- Best Regards, Laurentiu _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
